>> *) Lexical variables belong to the package they are declared in. (Or,
>> if not declared, the package to which they belong can be inferred.)
>
> Well, lexical variables don't belong to any package in Perl. They're not
> in the symbol table, hence why others can't mess with them. That's why a
> "my $var" is different from a "$pkg::var". The latter gets in the symbol
> table, the former doesn't.
Yes, the asterisked item is a proposal for a change, not a statement
of how things are now.
> Personally, I like your other idea much better - make lexicals the true
> default. Dynamics actually do have some advantages. For one thing, you
> can't do this with lexicals:
>
> use MyPackage;
> $MyPackage::DEBUG = 1;
> This would be a hard (read: impossible) thing for me to give up.
Yes, that's where the class accessor method part of the proposal
comes into play. These "package globals" can be nicely encapsulated
into standard accessor methods.
> I think something like this is a good idea. It's more intuitive too -
> hide your variables in your package unless you *want* to give others
> access to them.
[I'm snipping here to make this comment look like you're supporting my
idea. :) Actually, what I'm trying to say is that my idea helps
accomplish what you just said.]
Specifically, under this idea, variables can be accessed if they are
declared in the same or an enclosing scope, where a scope is a block
or a file. So, if you declare multiple packages within the same file,
a variable declared within that class is accessible from other
packages elsewhere in the file, while if you declare a package in
another file (which you'll normally be doing, I hope), you'll wind up
using an accessor method. (Or possibly exporting the variable?)
> If you're going to write an RFC on this, cool. Otherwise I will, just to
> keep it interesting. In particular I've "fallen in love" with the
> "your()" keyword. :-)
Well, you know what they say: if it looks like Perl, it probably
should be. :) As someone else mentioned, though, I think a lot of us
aren't quite clear on the distinction between this and our(). (I've
at least figured out enough to realize there is a distinction,
though.)
The plan is to stick this idea in the RFC I mentioned yesterday as
an optional add-on. My goal for the next hour or two is to write this
RFC, which will hopefully consist of a lot of cut-and-paste from my
last two major messages (plus some more thinking ... not everything is
there, yet). If you'd like to write some material on the implications
of this approach, please go ahead. Once I get the RFC done, if you
want things differently, or think this idea warrants its own RFC, we
can break them out.
I'll be submitting the RFC to the librarian as usual, but sending it
to this list as well to allow for immediate follow-up. Our deadline
is fast approaching.
Rushed,
J. David
