> Brutal critique enclosed... beware, I get right to the point. :)
Hmm, I enjoyed it, so I'm thinking I must
be more SM oriented than I thought...
> Me> # $_ is in main.
>
> $_ is always in main, even if the current package is something else.
Yes. I spent some time considering where this was
best revealed, and wrote it in in various places as
I drafted this article along with other stuff such as that
you can't my $_. But these details ultimately bit the
digital dust.
> Me> Amazingly, a huge number of high quality packages
> Me> are available publically for free in one nice big catalog
> Me> called CPAN. Some come with perl as standard.
>
> That'd be "modules", not "packages".
My early drafts tried to maintain the module/package
distinction. But on balance, I decided the distinction was
not merited given the kind of material I was trying to write,
especially given that I judged that the lie does little damage.
I found that the sleight of hand of focusing on packages
as against modules, and indeed on the content of a
package (its names) as against the package as a
singular entity, worked better than the alernatives I
came up with.
My intent was to say, you could go get a namespace
(set of names) by going to CPAN, and I thought that
that was a reasonable way of looking at it. Again, one
draft used 'namespace' throughout and deliberately
eschewed the terms module and package.
> 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.
main is the name of a namespace.
MY is my name for what is currently (perl 5) an
anonymous namespace. A package is a namespace,
and I felt that less damage was done in this article
if I also used the white lie that a namespace is a package.
I'm having second thoughts of course. Larry didn't use
the term package in connection with MY, he used the
term pseudo class. Indeed he specifically said that
one could use it to "import things lexically as well as
packagely", indicating that he did not see MY as a
package, or at least not as a "package".
Btw, MY was mentioned in Apocalypse II, which is where I
picked up on it. I have no idea what Damian said about it.
> Me> To use another package written by someone else,
> Me> you write something like:
>
> Me> use File::Copy;
>
> module!
Well, unless I'm getting something really screwed up
(always possible :>), I'd say both.
You have to use the module, to use the names in its
namespace, which is to say to use the namespace,
which is to say to use the package.
I do think the File::Copy wasn't the best choice to
illustrate some of these points. But I decided it was
good enough.
> Me> Fortunately, the 'use File::Copy' statement does more
> Me> than make the namespace available. It also imports
> Me> some names right in to your main package.
>
> Actually, the current package.
Argh. Bad mistake. Thanks.
> Me> use warnings;
>
> use warnings makes your program needlessly incompatible with 5.5.
> don't do that unless you're also using other 5.6 features.
A useful reminder. Thanks.
> 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.
Again, I think the device of fuzzing the notion of package
serves a purpose and it seemed to serve it well to me.
The truth is soooo much more complicated!
> Me> package Foo;
> Me> our $bar = 1; # set $bar from package Foo.
> Me> our $baz = 2; # set $baz from package Foo.
>
> "our" is 5.6, again needlessly incompatible with 5.5. "use vars
qw($bar)"
> is the close equivalent for all.
Oh I don't think "needless" is fair. I certainly wouldn't
have left our out, it's too neat. But I agree it was wrong
not to mention, in fact highlight, our's newness, as well
as to mention use vars.
> Me> If you redeclare a my, you throw away the old value:
>
> Me> my $foo = 1;
> Me> my $foo;
> Me> # $foo is undefined.
>
> This is almost certainly unintended, and merits a warning when
> warnings are enabled.
My 5.6.0 does indeed warn.
> Me> Only use local if you can't do what you want with my.
>
> You haven't even mentioned what local is, so it doesn't even suggest
> why you'd want this.
This section barely made my final editor's cut.
I deliberately didn't say how to use it. I mentioned it
enough to say, don't do that, and what you should be
doing instead. Any more seemed inappropriate.
local doesn't have any impact on namespaces or
use of names. It's only to do with values.
> Me> * In Perl 5, the package I call MY package is not often
> Me> called a package and can't be accessed in the same
> Me> way that other packages can be accessed. However,
> Me> in Perl 6, there will be a MY package, and, imo, it is
> Me> simpler to use the term package for all namespaces.
>
> This is news to me.
As explained above, I may be technically wrong on MY,
perhaps very wrong. I am not sure how this would impact
how I felt about the package and MY package "lies" I
used above to help people learn.
Thanks very much for your expert critique.
I have the original Learning Perl, and will be buying the
3rd edition if nothing more than to have a good bedside
read...
