Is there ever a good reason to use eval()?

问题:

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 PHP, Python, JavaScript, etc. Is there ever a situation where using eval() is justified (except perl)? And if not, why do so many languages implement it?

回答1:

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.

回答2:

eval is often the most expedient solution in situations where you are dynamically generating code. Even in languages that do not officially support eval, such as Java, they support reflection and modification of classes at runtime which are similar. (See books such as Stu Halloway's Component Development for the Java Platform )

回答3:

One reasonable use is if you have an interpreted language that you've built on top of another language, but you still want to provide some sort of "escape hatch" to allow people to get back to functions that are provided by the underlying language. One example is implementing Prolog in Lisp and then defining a predicate that allows direct use of Lisp functions via EVAL.

回答4:

For quick hacks, no problem because it's a handy quick-out.

In production code, consider it a last resort—and even then, try something else—because eval is difficult to control and thus dangerous. For anything non-trivial, implement a sublanguage.

回答5:

I used it once while pentesting a site - we wrote a small php script that decrypts and executes cryptographically signed payloads from non-logged HTTP data sources on the fly. This is the best use I've seen of eval() so far.

(In other words: no, I've never seen a good use for eval)

回答6:

Offhand thought: eval is good for implementing a poor man's expression compiler, or things like that. It's also a dull, rusty substitute for hygienic macros.

回答7:

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.

回答8:

Writing a cool textbook example on how easy it is to implement a "calculator" in language X? =)

回答9:

For debugging/testing an idea before implementing it the proper way.

For instance, you're making a toy calculator, and you want to work on the gui first, so you just use eval to do the "back-end" work in the background. Later, you come back to the back-end, scratch eval, and write a proper expression parser.

回答10:

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.

回答11:

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.