It seems to me that eval()
is treated with the same disdain that goto is. And by eval
, I mean a function for executing a string as code, as seen in
When creating/testing code segments eval is PERFECT!
Just build a basic scaffolding webpage with textareas and an eval button. Put code into a textarea then press eval button. It's faster than switching back and forth between your text editor and browser
eval
edit code
press eval button
switching method
edit code
press save extra step
switch to browser extra step
press reload
When doing alot of testing and tweaking on the code the minor extra steps can really add up. Plus you might forget to save creating confusion when testing.
Yes - when there is no other way to accomplish the given task with a reasonable level of clarity and within a reasonable number of lines of code.
This eliminates 99% of cases where eval
is used, across the board in all languages and contexts.
Maybe I use sh
and perl
too much, but I've never seen anyone treat eval with the disdain that goto
gets.
So my answer is: 'eval
is suitable when you are writing perl 5
and sh
'. The block eval
is the primary try
/catch
mechanism in Perl
and its hard to write safe code without it.
Eval is used when you need to 'generate' and execute code. And by generate I mean include from an external source (a file, a website, an 'agent') as well as create on the fly inside the program.
And the reason you would want to generate code, aside from the obvious examples of external modules and evaluation sites, is usually to dynamically reference the names of objects and properties in code.
The first example, btw, already happens when an HTML page is loaded and has a script tag, or in the event handler attributes of HTML tags -- so right from the start a web developer is taking advantage of EVAL, even if it's the browser making the call.
Which indirectly brings me to that second reason -- accessing the names of objects.. In some languages such as java, the ability to introspect reduces or eliminates the need to use java's eval. Turns out that since objects in Javascript are fully dynamic, a property access in Javascript is comparable to introspection in other languages, where you can access and refer to names created on the fly. In addition, Javascript has the 'call' and 'apply' functions to dynamically call functions with their parameters.
Lastly, related to executing code, one might use eval to increase performance -- instead of a multi level conditional or property access that determines which code to run or which object to use, one might create a minimal code snippet that might have to be executed hundreds of thousands of times, eval it to a function, and then just call that function. This might work with multimethods, for example, once the the particular arguments in use are determined. Granted, though, this is a few and far between reason since javascript treats functions as first class objects.