note
Tommy
<p>...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?</p>
<p>But that's not my biggest gripe. My gripe is that the <a href="http://search.cpan.org/~thaljef/Perl-Critic-1.118/lib/Perl/Critic/Policy/BuiltinFunctions/ProhibitStringyEval.pm">POD explanation itself</a> 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!</p>
<p>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.</p>
<div class="pmsig"><div class="pmsig-222307">
--
<br />
[Tommy]<br />
<code>$ perl -MMIME::Base64 -e 'print decode_base64 "YWNlQHRvbW15YnV0bGVyLm1lCg=="'</code>
</div></div>
1011110
1011153