Re^5: 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.

Comment on Re^5: Indirect variable name Download Code

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]
Re^7: Indirect variable name by moritz (Cardinal) on Nov 21, 2008 at 10:35 UTC
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]
Re^8: Indirect variable name by LanX (Saint) on Nov 21, 2008 at 10:58 UTC
Well... now we are entering the domain of taste. My arguments in short: symderefs are actually considered nonstrict and therefore evil they can't ever hinder optimization if they fail, nobody blames the compiler orthogonality between package vars and lexical should not be broken, even on the dark side of the force. 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]
Re^9: Indirect variable name by LanX (Saint) on Nov 21, 2008 at 11:20 UTC


Perl-Sensitive Sunglasses
	PerlMonks