...Which is what I've done, however I've found that the POD is most lacking, especially in the weak justification that to eval 'expressions' is bad because the 'expressions' are recompiled at each invocation and generate no compile-time warnings. Well, gee. I already knew that, and maybe (just maybe) I actually want that behavior for a reason. Is that so crazy? Does that make me evil?

But that's not my biggest gripe. My gripe is that the POD explanation itself really ... left much to be desired, particularly for this error. Sureley there's something deeper; surely there's some better explanation about why it's bad to eval 'expressions' beyond the two that are provided in the POD. If those are the only reasons not to eval 'expressions', then I don't think it's a bad thing to do when you specificall want the behavior it provides in the first place. Being able to do so is arguably one of the most powerful uses for perl: it can run itself!

And no, I haven't gone hunting for it in the PBP book (yet) because, again, I have no real page number to reference. I'll see what I can search out later on. If it turns out there's a greater justification to be found, I'll submit a patch to the POD. Otherwise I'll continue to be grateful that I can eval 'expressions' with Perl, because I've found several times that this (bad?) practice has helped me create some really awesome things through the years. Very fast template parsers with support for embedded perl expressions are one thing that comes to mind.

Stringy eval has its uses. Moose and Moo use it extensively for creating fast inlined accessors and constructors. Template-Toolkit uses it to create templates.

However it can also enable all sorts of ugly practices. For example, poor man's symbolic references...

use strict;

my $red    = '#ff0000';
my $green  = '#00ff00';
my $blue   = '#0000ff';

my $colour = 'green';
my $hex    = eval "\$$colour"; # symbolic reference
print "$hex\n";
[download]

When many newcomers turn to stringy eval, it's often because they're unaware of a better solution to their problem.

This is my problem with Perl::Critic. It takes a generally good guideline (stringy eval is often a bad idea; investigate other options first) and turns it into a concrete rule.

Yes, of course there's no critic comments but I don't really want to litter those around my code like rat droppings. (no strict and no warnings are already enough of an eyesore.)

perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

Exactly! Yes. What tobyink said.

Things like Moose and Catalyst wouldn't even be possible w/o stringy eval.

--
Tommy

I can appreciate your frustration when using Perl::Critic without a copy of PBP. Long ago, I asked O'Reilly if I could have permission to quote entire sections of their book in Perl::Critic's POD. They denied my request.

So we paraphrased PBP in the Perl::Critic documentation. If you see gaps or inaccuracies, feel free to file a bug (https://rt.cpan.org/Public/Dist/Display.html?Name=Perl-Critic) submit a patch (thaljef@cpan.org) or request a commit bit (http://perlcritic.tigris.org).

Soon after Perl::Critic was released, some folks wanted pages numbers for the French or German translations of the book. Others wanted links to pages on http://safari.oreilly.com instead of dead-tree page numbers. And now that we have all sorts of e-books, it is even harder to come up with a truly universal form of citation (which sounds like an interesting project in itself).

A stringy eval() is perfectly correct in some situations, usually having to do with dynamically generated bits of code. But in most other situations, a block eval is a better option.

All software is just the sum of a long series of decisions. Perl::Critic merely provides you with reasonable defaults for some of those decisions. But all those defaults will be wrong at some point. IMHO, mastering the language means understanding when and why they are wrong.

Jeffrey Thalhammer
Imaginative Software Systems