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

While sipping absinthe, Michael Winter heard a loud sucking noise coming
from alt.2600, and hastily inscribed the following unintelligible Sanskrit
in <news:CxRze.66202$G8.12674@text.news.blueyonder.co.uk>:

> [Follow-ups set to alt.2600 and alt.html; alt.php removed]
>
> On 09/07/2005 11:54, ^reaper^ wrote:
>
>> [Michael Winter wrote:]
>>
>>> On 08/07/2005 12:05, ^reaper^ wrote:
>
> [snip]
>
>>>> eval('document.all.'+name+'.style');
>>>
>>> Even then, it's not necessary:
>>>
>>> document.all[name].style
>>
>> Well, um, yeah. I did point that out.
>
> Not exactly. Calling a function and providing a variable as its argument
> is not the same as using a variable to construct a property name. In
> this case, the /result/ may be the same in IE and others, but the
> approach is most definitely different.

Oh sure. The point *was* you accomplish the same end result. Obviously the
approach is differnt. One does not even need to know js to see that. The
primary question is, does the browser support it? So, for example, the
*only* place I use eval is in this snippet from an old js file.

if( document.getElementById )return document.getElementById(name).style;
else if( document.links )return document.links[name].style;
else if( document.all )return eval('document.all.'+name+'.style');

Though, I do have some older code (that I snagged from somewhere) which
contains evals. Even then, that code is no longer on any of my sites.
*shrug*

No matter. As you can see, eval in the above example is a last ditch effort
in the event the others are not supported by the user's browser. That is,
of course, /assuming/ they do not have js disabled altogether.

> [snip]
>
>> Though the browsers have been converging wrt dom standards, so the
>> document.getElementById appears to work in the majority of cases.
>
> Yes. The all collection, in IE at least, should be deprecated. It only
> has value in IE4, and as a substitute for
>
> document.getElementsByTagName('*')
>
> in IE5.x (they will always return an empty collection).

Yep. And given that not everyone has migrated, and assuming you're aiming
for xbrowser compatibility...

>>> The eval function is best left for /arbitrary/ strings [...]
>>
>> True. It also tends to add a level of complexity that can potentially
>> obscure the underlying logic.
>
> Which was indeed part of Richard's argument, as well as the performance
> overhead of constructing, and disposing of, a new execution context for
> absolutely no reason.

True.

> [snip]
>
>>> r = eval('o[p](a[' + x.join('],a[') + ']);');
>
> [snip]
>
>> So, basically, you /could/ end up with:
>>
>> some function o[p]( a[0],a[1],a[2],...a[n] );
>>
>> Though I'm uncertain why one might wish to create such a function on
>> the fly.
>
> Not quite. Constructed string is a function call, not a function
> declaration or expression.
>
> The alternative to this is to create a large switch statement with each
> clause containing a separate function call with a finite number of
> arguments. In cases where there are a known number of necessary
> arguments, or at the very least a reasonable upper limit, then that
> alternative is preferable. In unknown cases, or where the upper limit is
> high, then the dynamic version I posted previously is probably better.

Why not simply set the function to accept an array argument?

> [snip]
>
>> I'm not sure what you mean by unnecessary. After all, there are
>> generally several ways to implement code.
>
> Precisely. The use of eval may be one of those ways, but as there is
> often an alternative, using eval in those cases is unnecessary and
> probably best avoided.

One way the eval /might/ come in handy is in a CBT scenario. It would
basically involve a series of lessons, with a practice run at the end of
each lesson, where the user tests out code snippets based upon what they
think they've learned. While they could obviously write their own js (or
inline it in an html), such an approach would log the users progress, as
well as sending the progress results to the instructor. The key here, is
that it's not just logging their coding efforts, but the debugging piece as
well (e.g., use a try/catch).

> [snip]
>
>> But anyway, here's one for you.
>
> [snipped code]
>
>> As you can see, the above is quite simplistic.
>
> Well, part of it seems to be missing, but yes there's nothing that
> complicated about it. However, I wouldn't call it particularly readable.
> I'll reserve any suggestions until I see the full code (preferably via a
> URL).

There is no "full code." It was nothing more than speculation in response
to other psoted code. Though, I did upload both example snippets (as per my
response to Michael).

> [snip]
>
>> 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. ^_~
>
> If the remaining code doesn't somehow mandate the use of eval, then I
> would have no idea why you chose to use it (beyond your favouritism :P).

Either that, or perhaps I enjoy causing peeps to bleed from teh ears, nose,
and mouth. My code hace been known to have that effect on peeps. Some folk
have even been known to turn to stone after just one look at my code. Think
medusa. ^_~

But seriously, were I attempting to implement a 'real' app, js prolly would
not be my first choice. And if I /did/ have some burning desire to use js,
I would likely use a db and generate the js & html code dynamically. This
would allow me the means to update eqns and add rules as necessary without
the overhead of mucking around with evals, etc. Though even then, the
dynamic bit would only occur in the event of an eqn or rules change.

> Mike
>
> alt.2600 remains cross-posted purely for your benefit, and perhaps that
> of OMH.

You wouldn't want teh /Guru/ of teh interweb to miss out on this, would
you? Though... you *do* realize he's a t0rll, right? o_O

> If you read a.html, or c.l.javascript, please set the appropriate follow-ups.

Nup, I don't. I have enuf on my plate as it is, and js & html are at teh
bottom... erm... rather not even on my lits atm. ^_~

--
"All cats are not gray after midnight. Endless variety --" -- 'The Notebook
of Lazarus Long,' Robert Heinlein

[Back to original message]