I'm dealing with some javascript code which uses eval to access properties of an object. For instance, I have the following:
var events = {}; events.flatUsers = {}; events.flatUsers.Clone = "I'm the Clone property"; events.flatUsers.Edit = "I'm the Edit property"; events.flatUsers.Delete = "I'm the Delete property";
var key = "flatUsers.Clone";
Right now, given 'events' and the key 'flatUsers.Clone', eval is used to retrieve events.flatUsers.Clone
window.alert( eval("events." + key) );
I'd like to get rid of eval, and since I cannot do just: events[key]
I wrote the following: function evaluate() { var context = this; for(var i = 0; i < arguments.length; i++) { context = context[arguments[i]]; } return context;
Ignacio Burgueño <igna...@emuunlim.com> writes: > Right now, given 'events' and the key 'flatUsers.Clone', eval is used > to retrieve events.flatUsers.Clone
> window.alert( eval("events." + key) );
...
> I wrote the following: > function evaluate() { > var context = this; > for(var i = 0; i < arguments.length; i++) { > context = context[arguments[i]]; > } > return context; > }
Thanks both! I was curious about the performance penalty. If case there's any interest, here are the times it took to run 100.000 times each method (eval, my first attempt (I called it 'evaluate') and Jorge's getProperty variation) It seems that in this particular (and simple) case, there's not a huge performance penalty by using eval.
Ignacio Burgueño <igna...@emuunlim.com> writes: > It seems that in this particular (and simple) case, there's not a huge > performance penalty by using eval.
Performance is not the (primary) reason to avoid "eval". A much bigger problem is that code crated by putting strings together at runtime is often fragile, and when it fails, it's hard to debug.
Lasse Reichstein Nielsen wrote: > Ignacio Burgueño <igna...@emuunlim.com> writes:
>> It seems that in this particular (and simple) case, there's not a huge >> performance penalty by using eval.
> Performance is not the (primary) reason to avoid "eval". A much > bigger problem is that code crated by putting strings together at > runtime is often fragile, and when it fails, it's hard to debug.
> /L
Indeed, you're right. I'd never use eval if I weren't sure where the code came from. I don't like the way it's being used in my code, but, well, I can't change that at the moment.
Ignacio Burgueño wrote: > Lasse Reichstein Nielsen wrote: >> Ignacio Burgueño <igna...@emuunlim.com> writes: >>> It seems that in this particular (and simple) case, there's not a huge >>> performance penalty by using eval. >> Performance is not the (primary) reason to avoid "eval". A much >> bigger problem is that code crated by putting strings together at >> runtime is often fragile, and when it fails, it's hard to debug.
> Indeed, you're right. I'd never use eval if I weren't sure where the > code came from. I don't like the way it's being used in my code, but, > well, I can't change that at the moment.
You have been shown how to change it right now.
PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300d...@news.demon.co.uk>
