Getting rid of eval for accesing "deep" properties

[Ignacio Burgueño]

Hi everyone.

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;
}

window.alert(evaluate.apply(events, key.split('.')));

Surely this can be improved, since I'm a newbie in Javascript. Any
suggestions?

Regards,
Ignacio Burgueño

[Lasse Reichstein Nielsen]

Ignacio Burgueño <ign...@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;
> }
>
> window.alert(evaluate.apply(events, key.split('.')));
>
> Surely this can be improved, since I'm a newbie in Javascript. Any
> suggestions?

Looks a little on the overkill side, but not far from what I would do:

function getProperty(obj, propPath) {
var parts = propPath.split(/\./g);
for(var i = 0; i < parts.length; i++) {
obj = obj[parts[i]];
}
return obj;
}

/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Jorge]

On Jul 31, 12:02 am, Lasse Reichstein Nielsen <l...@hotpop.com> wrote:
>
> function getProperty(obj, propPath) {
>  var parts = propPath.split(/\./g);
>  for(var i = 0; i < parts.length; i++) {
>    obj = obj[parts[i]];
>  }
>  return obj;
>
> }
>

Or

function getProperty (obj, parts) {
parts= parts.split(/\./g);
while (parts.length) { obj= obj[parts.shift()] }
return obj;
}

--Jorge.

[Ignacio Burgueño]

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.

| IE7 | IE6 |Opera |Safari| FF2 | FF3 |IE7(2)|
------------+------+------+------+------+------+------+------|
eval | 1468 | 2953 | 1547 | 812 | 4625 | 1151 | 8188 |
------------+------+------+------+------+------+------+------|
evaluate | 2110 | 4469 | 609 | 704 | 3828 | 676 | 2109 |
------------+------+------+------+------+------+------+------|
getProperty | 2234 | 5187 | 1047 | 343 | 3563 | 709 | 2250 |
-------------------------------------------------------------/

IE7 = 7.0.5730.11
IE7(2) = The same, but with script debugging enabled
IE6 = 6.0.2900.2180
Opera = 9.51.10081
Safari = 3.1.2 (525.21)
FF3 = 3.0.1
FF2 = 2.0.0.16

Tests in Firefox were run with all extensions disabled.

Regards,
Ignacio Burgueño

[Lasse Reichstein Nielsen]

Ignacio Burgueño <ign...@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.

[Ignacio Burgueño]

Lasse Reichstein Nielsen wrote:
> Ignacio Burgueño <ign...@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.

Thanks for your help, Lasse.

Regards,
Ignacio Burgueño

[Thomas 'PointedEars' Lahn]

Ignacio Burgueño wrote:
> Lasse Reichstein Nielsen wrote:
>> Ignacio Burgueño <ign...@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$8300...@news.demon.co.uk>