Posted by ^reaper^ on 07/10/05 18:37

While sipping absinthe, Richard Cornford heard a loud sucking noise coming
from alt.2600, and hastily inscribed the following unintelligible Sanskrit
in <news:daold5$9iv$1$830fa7a5@news.demon.co.uk>:

> ^reaper^ wrote:
>
>> Michael Winter wrote:
>
> <snip>
>
>>> I have seen other interesting uses for the eval function,
>>> but even they weren't really necessary.
>>
>> I'm not sure what you mean by unnecessary. After all, there
>> are generally several ways to implement code. And outside of
>> gross coding practices (e.g., extensive use of globals and
>> for-loops, to name but a couple), the tradeoffs are (or should
>> be) the primary factor in the final decision.
>>
>> But anyway, here's one for you.

[ 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. Even
>> in light of this rendition, wherein I am modeling a macro-like
>> scenario, there is no doubt a more efficient way to implement
>> the solution. And yes, I'm old school, so I tend to favor
>> macros. Unfortunately, unlike compiled langs, we don't have the
>> benefit of true macros (which are inlined at compile time).
>> Nonetheless, rather than completely giving away the store here,
>> I'll let you ponder this a bit of code, and even attempt to
>> guess, if you wish, why I may have chosen the route that I did...
>> my favoritism of macros notwithstanding. ^_~
>
> 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

> Because the code above makes (indirect) reference to the identifiers g,
> A, eqn and mult, none of which are defined above, it is impossible to
> say whether it does make a case for its eval use or not. Their
> significance and role in the code is unknown.

Yep, and all typos. *shrug*

> 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. Always up for a challenge, I came up
with the eval implementation (though my primary goal was to emulate macros
as well as provide an easy means to directly access the requisite eqns).
Which yes, I know, tends to cause some folk to bleed from teh ears, nose,
and mouth. But anyway...

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... though in context of
that guy's code, it's a start in teh right direction.

Nonetheless, my choice of the array of objects serves two purposes. One,
the necessity for if-then-else and/or switch statements is reduced.
Furthermore, I can dynamically generate the form fields by simply adding
additional eqns. And finally, reading discrete eqns vs trudging through
reams of code tends to be easier for financials folk. Which in and of
itself can be useful in the debug process. However, I would not really want
to rely upon js to write the forms. Were I actually implementing this, I
would likely store the eqns in a db, and dynamically generate both the html
*and* the js based upon some set of predefined rules.

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.

--
"The last good thing written in C++ was the Pachelbel Canon." -- Jerry
Olson

[Back to original message]