in reply to Re: my $var masked across package scope?
in thread my $var masked across package scope?

Thanks.

I must say, though I don't fully grok the different scopes, my tiny brain wants package scope to be its own lexical scope too. At least, if I redeclare a my variable that exists outside the package scope, I don't want the warning. If I want to access that farther-away variable, I should have that option too, as long as I haven't stepped on it with a closer my. (This is the way it works crossing lexical boundaries, it's just that package isn't a lexical boundary.)

Are there any benefits to having package not be a lexical boundary? (Just idle curiosity, as there's bleep-all chance of changing it now :D )

-QM
--
Quantum Mechanics: The dreams stuff is made of

Replies are listed 'Best First'.
Re^3: my $var masked across package scope?
by tobyink (Canon) on May 09, 2013 at 15:39 UTC

    "Are there any benefits to having package not be a lexical boundary?"

    It's sometimes handy to switch package mid-sub...

    use v5.12; use Data::Dumper (); # not importing Dumper function here sub d { package Data::Dumper; # please don't clobber @_ local *Indent = local *Terse = 1; say Dumper(@_); } d [1, 2, 3]; d {foo => 123};

    Also if package touched lexical variables it would probably confuse newbies into thinking that namespaces and lexical scopes have something to do with each other.

    package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
    /div