Re: my $var masked across package scope?

my declares a lexically scoped variable. A lexical scope continues until the closing brace (}) that ends the block it was defined in, or until the end of the file, whichever comes first.

{
  package Foo;
  my $foo = 1;
  package Bar;
  # can still see $foo here
  package Baz;
  # can still see $foo here
}
# cannot see $foo any more
[download]

While our variables are associated with a particular package, they too are lexically scoped:

{
  package Foo;
  our $foo = 1; # $foo is an alias for $Foo::foo
  package Bar;
  # $foo is still an alias for $Foo::foo here
  package Baz;
  # $foo is still an alias for $Foo::foo here
}
# cannot see $foo any more
[download]

For this reason, if you're defining multiple packages in the same file, it's a good idea to define them each within their own {...} block, so they don't accidentally leak variables. (Of course, sometimes - probably quite rarely - you'll actually want to share a lexical variable between the packages, in which case, just declare it right at the top before the first opening brace.)

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

Comment on Re: my $var masked across package scope? Select or Download Code

Replies are listed 'Best First'.
Re^2: my $var masked across package scope? by QM (Parson) on May 10, 2013 at 08:13 UTC
From your other post: If package touched lexical variables it would probably confuse newbies into thinking that namespaces and lexical scopes have something to do with each other. and above: If you're defining multiple packages in the same file, it's a good idea to define them each within their own {...} block, so they don't accidentally leak variables. Yes, agreed. In the future I'll be putting lexical scope around my package scopes. And in the event I want a variable private to the package scope, I can use `my`, and because of my improved practice, not worry about it. (Now is a good place for the cargo cult folks to interject.) I was wondering though, why both scope types have to be completely independent? Or rather, why we have to carry around the idea of multiple types of scope boundaries in relation to lexical variable? In my own head, a scope boundary is always a lexical scope boundary. Wrong as it is, I want to think that `my $var` declared inside a package scope isn't implicitly available outside. If I need it available outside, I should declare it outside, or otherwise arrange for it to be visible. I'm never concerned about variables leaking in, and often depend on it, so it seems this small conceptual tweak would save me some register space in my head when writing code. (It's harder to keep track of two similar but distinct items, compared to two completely different items. Compare "the electron and the proton" vs. "this electron and that electron" -- if only electrons came in colors.) If the idea of "a package scope boundary also being a lexical scope boundary" were actually implemented, would it cause any programs to break? (And if it did, would they have been correct programs anyway?) I'm not saying it's a trivial change, as suddenly package scope is a lexical scope. So, theoretically speaking, are there any downsides to proper nesting of package and lexical scope? -QM -- Quantum Mechanics: The dreams stuff is made of	[reply] [d/l] [select]
Re^3: my $var masked across package scope? by tobyink (Canon) on May 10, 2013 at 11:51 UTC
"If the idea of "a package scope boundary also being a lexical scope boundary" were actually implemented" It kind of already is implemented in Perl 5.14, albeit with a change in syntax: `package Foo { my $foo = 123; package Bar { # can still see $foo } } package Baz { # cannot see $foo }` [download] "would it cause any programs to break?" The change of syntax makes it opt-in. Use the old syntax; get the old behaviour. Thus nothing needs to break. "would they have been correct programs anyway?" Yes; it's perfectly reasonable to want to share a lexical variable between different packages. It's not a common need, I grant you. And if it were forbidden the sky would not fall; workarounds would be possible. But the ability to share a lexical variable can, in some cases result in much cleaner code than would be possible without it. `package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name`	[reply] [d/l]
Re^3: my $var masked across package scope? by Anonymous Monk on May 10, 2013 at 08:59 UTC
:) If the idea of "a package scope boundary also being a lexical scope boundary" were actually implemented, would it cause any programs to break? Yes, changing the rules breaks programs (And if it did, would they have been correct programs anyway?) Yes, they would have been correct, if they did what they were supposed to do :) I'm not saying it's a trivial change, as suddenly package scope is a lexical scope. So, theoretically speaking, are there any downsides to proper nesting of package and lexical scope? Every programming language with a `class` keyword uses parens to make scope, not the class keyword We already have proper nesting of package and lexical scope, so it could be said its a waste of time to redefine proper/nesting/scope rules for everyone But, a pragma can be created to turn package foo; ... package bar; into package foo;{...} package bar; {...} , using one of those magical B::Hooks:: modules	[reply] [d/l]