in reply to source filters in eval

For the sake of clarity, I would name it something entirely different from CORE::eval. But using '::' to indicate the version found in the current package is preferable to '&' so that you avoid '@_' being passed unmodified from the calling context to the scope of the subroutine. In general, '&' should only preface subroutine calls in very specific and peculiar circumstances.

That said, I'm wondering if you're planning to use this for some kind of code vetting, rather than the simple substitution in your example code? If so, then take a look at Safe and Opcode.

Update: ihb is correct.

"The dead do not recognize context" -- Kai, Lexx

Replies are listed 'Best First'.
Re: Re: source filters in eval
by ihb (Deacon) on Feb 25, 2003 at 10:56 UTC
    But using '::' to indicate the version found in the current package ...

    The :: doesn't indicate the subroutine is found in the current package. On the contrary. It clearly (?) specifies which package the subroutine is found in, and that's main.

    ... is preferable to '&' so that you avoid '@_' being passed unmodified from the calling context to the scope of the subroutine

    Using & doesn't necessarily mean @_ gets passed. That only happens if there is no parenthesis. If you look at the OP, you'll see that it asks about &eval(). And looking at the prototype of &eval makes it clear that it always is supposed to be called with one argument, so the behaviour you speak of is quite unlikely to happen.

    So, using :: is not preferable to &. The only advantage is that it still honours prototypes, but the downside is that you package qualify the subroutine so when you move it you'll have to rename all calls to it. The real fix, as you say, is to not name it "eval".

    ihb
[reply]
[d/l]
[select]
Re: source filters in eval
by asdfgroup (Beadle) on Feb 25, 2003 at 11:11 UTC
    Hi,
    Maybe this is not clear indicated reasons of this trick (and re-inventing of eval).
    Problem is indicated in subject of node. E.g. source filters in 'eval' code magically don't work.
    So this is workaround of this problem and this post mean questions :
    - Is this is correct workaround ?
    - Can this be done more simply ?
    - And if it can't, how we can make this work magically ? E.g. if we can override (re-define) CORE::eval
[reply]
[d/l]

      Isn't that because you used the expression (quoted) form of eval? The code would have already been compiled and (I think) source filters are applied at compile time. What happens if you try a block style eval?

[reply]
        You right, but I can't use block style eval. I need to eval code located in other file and content of this file should be preprocessed first in some way... As trivial example I need to load this code in temporary package and import some function (from other module) into this package: 
        $content = `cat somefile.pl`;
eval "package $TEMPPACKAGE;".
    "use Some::Module qw(somefunctions);".
    $content;

        [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom