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

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

Replies are listed 'Best First'.
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]

In Section Seekers of Perl Wisdom