Re: Small examples of string eval

[eyepopslikeamosquito]

Most Perl experts discourage the use of string eval. For example:

• merlyn in •Re^2: Dynamically constructed function calls states: Do not resort to eval-string if other means are available. You're firing up the compiler (slower than almost any other solution), and exposing yourself to hard to debug and hard to secure practices.
• TheDamian in Perl Best Practices in Chapter 8 has a guideline titled: Avoid string eval. Damian argues that string eval can be slow; produces run time warnings rather than more desirable compile time warnings; and code that generates other code tends to be harder to maintain. He further advises you to use anonymous subroutines and the CPAN Sub::Installer module when you have a need to create new subroutines that are built around some expression that the user supplies.

Update: In this quiz of the week MJD states:

A good rule of thumb is that unless what you're trying to do is most clearly described as "compile and run arbitrary Perl code", it's probably a mistake to use 'eval' to do it.

[BrowserUk]

But each of them knows when to eshew complicated eval-avoidance-schemes, in favour of simplicity.

merlyn See name_to_page() in CGI::Prototype::Hidden, new() in CGI::Prototype::Mecha, type() in File::Finder, the grammer for Inline::Spew.

TheDamian See import() in Attribute::Handlers, import() in Attribute::Types, install_dispatch() in Class::MultiMethods, initialise() & new() in Class::Std... I stopped here with D-Z to go.

Dominus memoize() in Memoize, in Memoize::AnyDBM_File, fill_in() inText::Template, TIEARRAY() in Tie::File.

And before anyone leaps to these authors defense, there is no need. String eval is a tool. Avoiding it where practical is common sense; eshewing at all costs is illogical.

I'm betting that Perl6 will retain string eval in some form.

[spurperl]

I was just going to reply that MJD's HOP also has a few legitimate uses of string eval. As you said it's a tool, a powerful tool, and as such it should be used with great caution.

I really hope Perl 6 won't drop the string eval, having it IMHO is essential to any dynamic language.

[stvn]

He (TheDamian) further advises you to use anonymous subroutines and the CPAN Sub::Installer module when you have a need to create new subroutines that are built around some expression that the user supplies.

While Sub::Installer is certainly a good idea (insulating the user from the evils of symbol table manipulation, which is at least as dangerous as string eval in the 'wrong' hands). It's code can hardly be considered to contain "Best Practices" IMO. It clearly abuses UNIVERSAL in a way which affects not only the code which uses it, but all other running Perl code. This is the offending code:

package UNIVERSAL;
use base 'Sub::Installer';

This would mean that every Perl object will respond true to the query $object->isa('Sub::Installer'). Again, IMO, that is not a Best Practice, but instead a really really bad idea.

Sorry, I am a little passionate about code which tramples over the Perl 5 object model like this.

But fear not! CPAN will save the day. As an alternative, I offer Sub::Install an excellent module which does not assert it's will upon your entire runtime.