Reply Via Newsgroup <re****************@please.com> writes:
I don't use eval alot in my scripts - but I do use it - and since I
always out to learn more / improve my javascript skills, I'm curious
why something I thought 'normal' would be considered abnormal.
Can someone put some meat on the bones of 'eval' - its advantages (if
any) and its disadvantages (which seem great).
As you might guess, it's not the first time someone has questionend
the "eval is evil" slogan :) It even made the FAQ.
<URL:http://jibbering.com/faq/#FAQ4_40>
The short argument for not using eval is:
"It's shooting pidgeons with cannons."
Sure, it get's the job done, but it's harder to control and takes a
lot more resources than needed, and when it fails, it fails
spectacularly (read: blows up in your face).
There is (almost) no situation where there isn't another method that
also does the job, and both more efficiently and a lot safer.
With "more efficient" I mean that it uses fewer resources. The "eval"
function works by first turning its argument into a string, then it
parses the string as a Javascript program and finally it evaluates
it. This is a very expensive operation, and the generality of it is
only needed in rare cases that most people writing web pages will
never meet.
With "safer" I mean that it it is less likely to fail spectacularly.
Since eval can execute arbitrary Javascript expressions, passing the
wrong argument can cause arbitrary errors. On a server, using eval on
a user supplied string is a *very* bad idea. On a client, the main
problem is that the error message is harder to connect to the actual
error, and that, e.g., syntax errors in eval'ed code will only be
detected at run time, not when the script is loaded. So: eval
both introduces more possible errors and hides existing errors.
The two most common (mis)uses of eval are:
1) converting strings to numbers.
There are plenty of dedicated functions and operators for just this
problem: parseInt, parseFloat, Number, the prefix plus operator, most
mathematical operators (string*1,string/1,string-0). Of these, the
prefix plus is the fastest by a small margin. It is roughly *50* times
faster than using eval (in my browser).
2) accessing properties using a computed name.
Example:
eval("document.images.img"+n+".src")
Again it is inefficient, here compared to using square-bracket
notation for property access:
document.images['img'+n].src
It is also error prone. There is no syntax check, and if the variable
"n" contains something you didn't expect, then the failure can be
hard to find. If the property is called something that is not an
identifier (typically "foo[]", used by PHP for form controls, or
perhaps "foo1.1"), then the eval method fails completely.
This is what I take as a sign that the author doesn't know the
language very well. Often the reason for using eval like this is
that they don't know about this way to do property access, which
is a fundamental part of the language. Using eval like this is a
crutch that allows them to stagger along, getting something to
run, whereas knowing the language would let them run :)
Then there is the third misuse (which the mentioned calendar program
also sufferend from): throwing in an eval "just for good measure",
even though someone who knows the language can see that it doesn't do
anything. :)
So, eval isn't evil, that's just a good slogan :)
Eval is *very* slow and dangerously error prone!
For *that* reason, it should be avoided in 99.999% of all cases. As
for the remaining two, when you meet them, you'll hopefully know the
language well enough to be able to recognize them.
/L
--
Lasse Reichstein Nielsen -
lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
