(Skip to recap at end for important info!)
>>>>> "Me" == Me <[EMAIL PROTECTED]> writes:
Me> # $_ is in main.
>>
>> $_ is always in main, even if the current package is something else.
Me> Yes. I spent some time considering where this was
Me> best revealed, and wrote it in in various places as
Me> I drafted this article along with other stuff such as that
Me> you can't my $_. But these details ultimately bit the
Me> digital dust.
No, those are unrelated properties. $_ is always in package main,
simply because it's forced to be that way. Like ARGV is always in
package main. However, you can say "my $ARGV" and it works just fine.
So the property of "$_" always being in package main is not related to
the property of "$_" not being available to be lexically scoped.
I think you are still confusing "package" with "lexical". Lexical
scope is not a package! Dare I repeat this three more times? :)
Me> My early drafts tried to maintain the module/package
Me> distinction. But on balance, I decided the distinction was
Me> not merited given the kind of material I was trying to write,
Me> especially given that I judged that the lie does little damage.
It does a lot of damage. I can use packages without ever touching a
module. A module may contain multiple packages. In fact, a "package"
doesn't really exist as an entity.. it's merely a naming convention
for the symbol table. It doesn't really "live" anywhere, the same way
a module does.
Me> I found that the sleight of hand of focusing on packages
Me> as against modules, and indeed on the content of a
Me> package (its names) as against the package as a
Me> singular entity, worked better than the alernatives I
Me> came up with.
You haven't been in my packages-references-objects-modules (PROM)
class, or read much of Effective Perl Programming, I take it?
Me> My intent was to say, you could go get a namespace
Me> (set of names) by going to CPAN, and I thought that
Me> that was a reasonable way of looking at it. Again, one
Me> draft used 'namespace' throughout and deliberately
Me> eschewed the terms module and package.
But a "namespace" is too generic, especially when you are lumping
"lexical", "package", and "module" into that bucket, which have
significant distinctions, even in terms of levels.
Me> Apart from main and MY, all other packages have to be
Me> given a name.
>>
>> "main" is a name! "MY" is not a package.
Me> main is the name of a namespace.
You might as well say "main is a noun". It's about as meaningful.
"main" is a package name, not a namespace. Packages distinguish the
parts of a global symbol table, which is ONE namespace. $main::a and
$foo::b are just two equally valid names in the one single global
symbol table. To artificially distinguish those two as being members
of seperate "namespaces" is to introduce confusion. Perhaps you are
merely presenting the confusion you already have. :)
Me> MY is my name for what is currently (perl 5) an
Me> anonymous namespace. A package is a namespace,
No, it's not, and I'm more convinced now that this is your confusion.
Me> and I felt that less damage was done in this article
Me> if I also used the white lie that a namespace is a package.
No, it breaks models that you don't want broken.
Me> I'm having second thoughts of course. Larry didn't use
Me> the term package in connection with MY, he used the
Me> term pseudo class. Indeed he specifically said that
Me> one could use it to "import things lexically as well as
Me> packagely", indicating that he did not see MY as a
Me> package, or at least not as a "package".
Right.
Me> Btw, MY was mentioned in Apocalypse II, which is where I
Me> picked up on it. I have no idea what Damian said about it.
Yeah, I missed that, because I considered the point trivial, I guess.
Me> To use another package written by someone else,
Me> you write something like:
>>
Me> use File::Copy;
>>
>> module!
Me> Well, unless I'm getting something really screwed up
Me> (always possible :>), I'd say both.
Me> You have to use the module, to use the names in its
Me> namespace, which is to say to use the namespace,
Me> which is to say to use the package.
Not at all. I can say $File::Copy::foo without ever saying "use
File::Copy". It might not be meaningful, but it's not a necessary
component. Again, you're confusing gas with the car.
Me> my $foo;
>>
Me> so that $foo now belongs in the MY package.
>>
>> $foo is now a lexical, not part of any package, and has a scope and
>> persistence related to where it is defined, no longer a global.
Me> Again, I think the device of fuzzing the notion of package
Me> serves a purpose and it seemed to serve it well to me.
Me> The truth is soooo much more complicated!
No, it's simpler, if you stop confusing things.
Me> I deliberately didn't say how to use it. I mentioned it
Me> enough to say, don't do that, and what you should be
Me> doing instead. Any more seemed inappropriate.
Me> local doesn't have any impact on namespaces or
Me> use of names. It's only to do with values.
But it applies only to package vars, not to lexical vars. So, yes, it
has everything to do with namespaces, since it works with only one and
not the other.
Me> Thanks very much for your expert critique.
Me> I have the original Learning Perl, and will be buying the
Me> 3rd edition if nothing more than to have a good bedside
Me> read...
Thank you.
So, to recap:
There are two namespaces, lexical and global (also called
package).
"my" creates lexical variables, and shadow any global variables
that do not use colons. No operator is needed to create global
variables, as they are automatically in place on first reference.
The global namespace is broken into "packages" for notational
convenience, but that doesn't change the semantics of it still
being one global table. Any global (package) variable is
available in any scope. The "local" operator may be used to give
such a variable a temporary value for a particular runtime scope.
A "current package" allows you to use shorter names for package
variables, providing a default prefix for variables without
colons. The initial "current package" is "main". The "package"
directive (lexically scoped) changes the "current package". When
strict is enabled, the default prefix is disabled for
scalars/arrays/hashes, so a scalar/array/hash must either be a
lexical variable in scope, or a global variable declared with
"our" (5.6) or "use vars" (all) or a global variable with colons.
Some variables, such as those using _ or ARGV, are forced into
main regardless of the "current package".
A module must include at least a few entries in a package of the
same name (to manage the import process), but can use any other
package prefixes at will. The module's import mechanism may also
alias some global variables to other packages, typically the
invoker's current package.
These are points that either you don't have clear (from reading your
stuff), or you are deliberately muddying, and I think with devastating
results.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
