in reply to Re^4: Indirect variable name
in thread Indirect variable name

sorry I don't understand this argumentation, if you want to make a symderef on a lexical you can always use eval

Not if a closure didn't include that variable: 

use strict;
use warnings;

my $sub = do {
    my $x = 4;
    my $y = 5;
    sub {
        my $a = shift;
        print 'Accessing $x: ', $x + $a, "\n";
        print 'Accessing $y from eval: ', eval '$y + $a', "\n";
    };
};

$sub->(2);
__END__
Accessing $x: 6
Use of uninitialized value in addition (+) at (eval 1) line 1.
Accessing $y from eval: 2

[download]

Whoops. Perl knows at compile time which lexicals in outer scopes are needed for a closure, and only stores those.

With the current current behaviour only eval can be used to detect that. That's OK because eval has the "evil, don't use" stigma on it.

If symbolic deref would also look in lexicals, every deref might break this optimization.

I hope it's a bit clearer now.

Replies are listed 'Best First'.
Re^6: Indirect variable name
by LanX (Saint) on Nov 21, 2008 at 10:01 UTC
    Thanks, but

    > That's OK because eval has the "evil, don't use" stigma on it.

    Well which is perfectly the same with symderef, that's why it's not strict!

    When the code breaks, the compiler can't be blamed. No optimization would be hindered by that.

    Cheers Rolf

[reply]
      Well which is perfectly the same with symderef, that's why it's not strict!

      symbolic derefs are not syntactically distinguished from "normal" derefs, so I do see a difference to the case with eval.

[reply]
        Well... now we are entering the domain of taste. My arguments in short:
        1. symderefs are actually considered nonstrict and therefore evil
        2. they can't ever hinder optimization
        3. if they fail, nobody blames the compiler
        4. orthogonality between package vars and lexical should not be broken, even on the dark side of the force.
        5. they have a big advantage to eval, since there is no security risk of code infiltration.

        Cheers Rolf

        UPDATE: I think your arguments are valid to proof why real refs are much better than the evil symbolic ones. There is no doubt ... but sometimes you can't help but getting dirty to solve a problem. That's why perl has tools like eval helping to dig in the dirt.
[reply]

In Section Seekers of Perl Wisdom