Posted by Michael Winter on 07/09/05 17:53

[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.

[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).

>> 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.

[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.

[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.

[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).

[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).

Mike


alt.2600 remains cross-posted purely for your benefit, and perhaps that
of OMH. If you read a.html, or c.l.javascript, please set the
appropriate follow-ups.

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[Back to original message]