|
|
Posted by ^reaper^ on 07/11/05 06:36
While sipping absinthe, Richard Cornford heard a loud sucking noise coming
from alt.2600,alt.html,comp.lang.javascript, and hastily inscribed the
following unintelligible Sanskrit in
<news:das3a7$hmi$1$8302bc10@news.demon.co.uk>:
> ^reaper^ wrote:
>> Richard Cornford wrote:
>>> ^reaper^ wrote:
> <snip>
>> [ snecked and moved to http://www.spyderware.net/source/calc1.js ]
>>
>>>> As you can see, the above is quite simplistic. This example
>>>> btw, was born out of a discussion involving an original 200+
>>>> line script that was primarily if-then-else ad nauseum. ...
> <snip>
>>> In a functional programming language like javascript, where
>>> functions are first class objects and may be anonymously
>>> created, passes around by reference and called indirectly,
>>> most macro concepts are amenable to implementation with
>>> functions.
>>
>> Like this, for example?
>>
>> http://www.spyderware.net/source/calc2.js
>
> Disregarding the syntax errors, variables leaking into the global
> namespace, etc, yes much more like that.
Yes, that code no doubtely has a ton of syntax errors, among the other
things (as you've so noted).
> But you have re-introduced the switch statement, a step backwards.
> And for some reason the code that was being evaled and is now in the
> (almost) function bodies is trying to interact with the DOM. My
> preference would be to have a function that calculates an expression
> do just that an return a numeric value as the result. Leaving it to
> the code that calls the function to decide what needs to be done with
> the result. One of the consequences of attempting to move the DOM
> manipulation to inside the - calcs - functions is that when one of
> them calls two or the others the result will not be expected
> calculation, or the expected text display in the browser.
>
> My take on this would go more like:-
[ snecked and moved to http://www.spyderware.net/source/calc3.js ]
Very nice. I agree about removing the dom assignment from the function. In
fact, when I originally wrote up that version, I did not assign the dom
element value in the function. After all, there are a significant number of
reasons not to do so. One thing that approach does however (that is, if it
weren't buggy), is to assign values to both fvLumpSum and fvAnnuity dom
elements, should the user choose an fv calc. So the resulting output would
contain all three calcuation results, rather than the single fv result.
Though, that I think of it, that bit would completely fail for the fv, as
it assumes a return value from the other fns. No matter. I like the way you
encapsulated your fns in the period and calcs objects. Much more readable
(and prettier ^_~). And yes, even in my half-assed attempt, there was
really no reason to reintro the switch. ^_~
> <snip>
>>> However, in considering the factors that might influence
>>> implementation decisions the cost of maintenance is
>>> inevitably a significant factor.
>>
>> I would tend to agree. Nonetheless, as I noted earlier, that
>> bit came about after someone psoted this:
>>
>> <news:MPG.1d2c2ffd17c9b4739897c8@news.alt.net>
>>
>> and claimed it could not be reduced. ...
> <snip>
>
> A conclusion that seems to follow from nothing more than not trying
> very hard.
>
>> I certainly wouldn't hard code the eqns as I did in the
>> above examples. Nor would I necessarily implemnt it in
>> the manner that I did. After all, from the production
>> pov, smaller is not always better...
>
> And certainly not when smaller means hiding code inside string literals.
No chit, eh? But seriously, I was attempting to find an example (just one)
where one might make a legit argument for using teh eval. Since you've done
quite a nice job of deconstructing this example, I'm pretty much out of
ideas, atm. Though both you and Michael have provided some great ideas for
cleaning up the pos js code I use on my sites. Now if I can only find one
of them round tuits, I'll have it made in teh shade! ^_~
> <snip>
>> As for the functions, I can see where they would be the
>> better choice. Assuming, that is, the switch statement
>> doesn't grow beyond what it is in the exmaple snippet.
>
> Inevitably there will be a bigger context that would say more about how
> the code should be implemented, but the switch should be avoidable in
> any case.
Yep.
--
"The last good thing written in C++ was the Pachelbel Canon." -- Jerry
Olson
Navigation:
[Reply to this message]
|