2001 YAPC mp3s [was RE: tutorial on my/our/use/package/local]
The proper address to find these at would be http://www.crystalflame.net/yapc/ - I'd prefer not linking to the files directly as this prevents people from seeing the other talks and the mirrors that may be available. As a side effect of this, the URL in Chas' message is now a 404; the correct URL is above. Sorry for the confusion. R. > - Original Message - > From: "Chas Owens" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, June 21, 2001 8:23 PM > Subject: Re: tutorial on my/our/use/package/local > > > > I just listened to the mp3 of it this morning, fascinating > stuff. It > > almost makes me sad I started learning Perl now and not next year. > > > > http://www.crystalflame.net/keynote.mp3 > > > > slide show: > > http://www.yetanother.org/damian/Perl6/YAPC_talk.pdf > > > > On 21 Jun 2001 08:32:49 -0700, Randal L. Schwartz wrote: > > > >>>>> "Jeff" == Jeff 'japhy' Pinyan <[EMAIL PROTECTED]> writes: > > > > > > Jeff> Damian dropped the bomb at YAPC. You'll be able to > access the > padlist, > > > Jeff> using a mechanism like C<$MY.foo>. > > > > > > Ah, that's what happens when you spend a week at sea with > Tim Bunce on > > > a Geek Cruise (www.geekcruises.com) instead of being in > Montreal. :-) > > > > > > -- > > > Randal L. Schwartz - Stonehenge Consulting Services, Inc. > - +1 503 777 > 0095 > > > <[EMAIL PROTECTED]> 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! > > > > > -- > > Today is Boomtime, the 26th day of Confusion in the YOLD 3167 > > You are what you see. > > > > > > >
Re: tutorial on my/our/use/package/local
On Thu, Jun 21, 2001 at 01:56:31PM -0700, Randal L. Schwartz wrote: > Ahh, I think I see the problem. The syntax for $foo actually means > the variable $main::foo (when main is the current package), and > $main::foo is a global variable, but $foo is a "local to the package" > variable. So perlmod is arguing it from a syntax point of view, and > I'm arguing it from a semantics point of view. This syntax view is how my concept of packages has always worked. $main::foo and $Foo::foo, despite being having the same name, foo, are in seperate namespaces. I think you're approaching it as $main::foo and $Foo::foo having different names entirely, with funny, but standard, :: sequences in their names. > perlmod jumps right to syntax, leading to people thinking there's a "MY > package" which causes loud cognitive dissonance in my ears. The problem with the concept of a "MY" package is it doesn't behave as every other package in Perl behaves. You can't carry a package variable around in a closure, you can't mask a package variable of the same name in nested scope (syntactically it would appear that way with local, but it isn't really), and you can access a package variable from an entirely seperate scope (i.e. not a nested scope) from the one it was initialized in. Due to the differences it would actually be more difficult to think of the lexical scope as a package, because then you'd have to remember a bunch of exceptions. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: tutorial on my/our/use/package/local
> "Peter" == Peter Scott <[EMAIL PROTECTED]> writes: Peter> At 12:13 PM 6/21/01 -0700, Randal L. Schwartz wrote: 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. :) Peter> Quoth perlmod: Peter> "Perl provides a mechanism for alternative namespaces to protect Peter> packages from stomping on each other's variables. In fact, there's Peter> really no such thing as a global variable in Perl. The package Peter> statement declares the compilation unit as being in the given Peter> namespace." >> 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. Peter> On the namespace point, seems a bit harsh given the precedent in the Peter> documentation. Hmm. That section of perlmod also is contrary to how it actually works. I wonder if there's a different meaning for "global" there. I can read it different ways, some of which supports what I said earlier, and some of which contradicts it. Ahh, I think I see the problem. The syntax for $foo actually means the variable $main::foo (when main is the current package), and $main::foo is a global variable, but $foo is a "local to the package" variable. So perlmod is arguing it from a syntax point of view, and I'm arguing it from a semantics point of view. I think the semantics underlying the syntax are important, and should be understood first. perlmod jumps right to syntax, leading to people thinking there's a "MY package" which causes loud cognitive dissonance in my ears. I wonder if I shouldn't pretty-up my recap and submit it as a docpatch, which I think would probably reduce further misunderstanding. We take a stab at this in the new llama, although we don't mention package except to look at the pretty colons in a "use" directive. A llama-sequel (alpaca? :) book might address that head-on though, at the level and quality of explanation in the llama. Hmm, I wonder if there's one of those in the works now that Tom Phoenix and I are done with the llama? :-) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> 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!
Re: tutorial on my/our/use/package/local
At 12:13 PM 6/21/01 -0700, Randal L. Schwartz wrote: >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. :) Quoth perlmod: "Perl provides a mechanism for alternative namespaces to protect packages from stomping on each other's variables. In fact, there's really no such thing as a global variable in Perl. The package statement declares the compilation unit as being in the given namespace." >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. On the namespace point, seems a bit harsh given the precedent in the documentation. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: 2001 YAPC mp3s [was RE: tutorial on my/our/use/package/local]
Sorry, I just grabbed the links from use Perl;. I will keep you wishes in mind in the future. On 21 Jun 2001 12:40:24 -0700, Richard Soderberg wrote: > The proper address to find these at would be > http://www.crystalflame.net/yapc/ - > I'd prefer not linking to the files directly as this prevents people > from seeing the other talks and the mirrors that may be available. > > As a side effect of this, the URL in Chas' message is now a 404; the > correct URL is above. Sorry for the confusion. > > R. > > > - Original Message - > > From: "Chas Owens" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, June 21, 2001 8:23 PM > > Subject: Re: tutorial on my/our/use/package/local > > > > > > > I just listened to the mp3 of it this morning, fascinating > > stuff. It > > > almost makes me sad I started learning Perl now and not next year. > > > > > > http://www.crystalflame.net/keynote.mp3 > > > > > > slide show: > > > http://www.yetanother.org/damian/Perl6/YAPC_talk.pdf > > > > > > On 21 Jun 2001 08:32:49 -0700, Randal L. Schwartz wrote: > > > > >>>>> "Jeff" == Jeff 'japhy' Pinyan <[EMAIL PROTECTED]> writes: > > > > > > > > Jeff> Damian dropped the bomb at YAPC. You'll be able to > > access the > > padlist, > > > > Jeff> using a mechanism like C<$MY.foo>. > > > > > > > > Ah, that's what happens when you spend a week at sea with > > Tim Bunce on > > > > a Geek Cruise (www.geekcruises.com) instead of being in > > Montreal. :-) > > > > > > > > -- > > > > Randal L. Schwartz - Stonehenge Consulting Services, Inc. > > - +1 503 777 > > 0095 > > > > <[EMAIL PROTECTED]> 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! > > > > > > > -- > > > Today is Boomtime, the 26th day of Confusion in the YOLD 3167 > > > You are what you see. > > > > > > > > > > > -- Today is Boomtime, the 26th day of Confusion in the YOLD 3167
Re: tutorial on my/our/use/package/local
(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 s 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 namespa
Re: tutorial on my/our/use/package/local
I just listened to the mp3 of it this morning, fascinating stuff. It almost makes me sad I started learning Perl now and not next year. http://www.crystalflame.net/keynote.mp3 slide show: http://www.yetanother.org/damian/Perl6/YAPC_talk.pdf On 21 Jun 2001 08:32:49 -0700, Randal L. Schwartz wrote: > > "Jeff" == Jeff 'japhy' Pinyan <[EMAIL PROTECTED]> writes: > > Jeff> Damian dropped the bomb at YAPC. You'll be able to access the padlist, > Jeff> using a mechanism like C<$MY.foo>. > > Ah, that's what happens when you spend a week at sea with Tim Bunce on > a Geek Cruise (www.geekcruises.com) instead of being in Montreal. :-) > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <[EMAIL PROTECTED]> 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! > -- Today is Boomtime, the 26th day of Confusion in the YOLD 3167 You are what you see.
Re: tutorial on my/our/use/package/local
> 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 s 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 wron
Re: tutorial on my/our/use/package/local
> "Jeff" == Jeff 'japhy' Pinyan <[EMAIL PROTECTED]> writes: Jeff> Damian dropped the bomb at YAPC. You'll be able to access the padlist, Jeff> using a mechanism like C<$MY.foo>. Ah, that's what happens when you spend a week at sea with Tim Bunce on a Geek Cruise (www.geekcruises.com) instead of being in Montreal. :-) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> 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!
Re: tutorial on my/our/use/package/local
On Jun 21, Randal L. Schwartz said: >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. Damian dropped the bomb at YAPC. You'll be able to access the padlist, using a mechanism like C<$MY.foo>. -- Jeff "japhy" Pinyan [EMAIL PROTECTED] http://www.pobox.com/~japhy/ I am Marillion, the wielder of Ringril, known as Hesinaur, the Winter-Sun. Are you a Monk? http://www.perlmonks.com/ http://forums.perlguru.com/ Perl Programmer at RiskMetrics Group, Inc. http://www.riskmetrics.com/ Acacia Fraternity, Rensselaer Chapter. Brother #734 ** Manning Publications, Co, is publishing my Perl Regex book **
Re: tutorial on my/our/use/package/local
Brutal critique enclosed... beware, I get right to the point. :) > "Me" == Me <[EMAIL PROTECTED]> writes: Me> Unless you declare a name as being in some other Me> package, a name is assumed to be in the main package: Me> $_ = 1; Me> # $_ is in main. $_ is always in main, even if the current package is something else. 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. Me> Others need to be pulled in from the Internet. You can Me> browse and search CPAN using a web browser: Me> http://search.cpan.org/ Me> More on this in a footnote**. That'd be "modules", not "packages". A package is a mechanism for carving up the symbol-table (global) namespace. A module is a reusable chunk of code. A module almost certainly uses a package, but a package doesn't have to be a module. Or, package is to module what gas is to a car. Best not to confuse the two. Me> -- 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> To use another package written by someone else, Me> you write something like: Me> use File::Copy; module! 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. Me> If you are writing more than a one liner, you should Me> start your scripts with: Me> #!/usr/bin/perl Me> use warnings; Me> use strict; use warnings makes your program needlessly incompatible with 5.5. don't do that unless you're also using other 5.6 features. Me> As already stated, most of the names you come up Me> with will refer to things that are, well, yours, so you Me> typically write things like: 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> 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. 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. 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. 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. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> 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!
tutorial on my/our/use/package/local
There's plenty of existing doc, but in the name of TMTOWTDI...
Asbestos suit donned. Criticisms welcome.
--
If you are wondering about things like:
use strict;
my $foo;
our $bar;
local $baz;
"explicit package"
then this article might be of help.
--
Before we can understand a noun, like "Paris", or a verb,
like "move", we need to understand the context. Does
Paris refer to the town in Texas, USA, or the city in France?
A perl script is aware of multiple "namespaces" and the
meaning of a word is often established by associating
it with one or other of these namespaces.
One important job you have in coding anything but the
simplest perl script is to let perl know which namespaces
should be available and which namespace should be
used for context when you use a given word.
--
In perl, namespaces are called packages.
Every perl script automatically knows of two packages,
main and MY*.
--
Unless you declare a name as being in some other
package, a name is assumed to be in the main package:
$_ = 1;
# $_ is in main.
--
In general, you should not be lazy and let your names
fall in to the default main package. Instead, you should
declare variables you create as being in MY package:
my $foo = 1;
foreach my $element (@array) {
Unless you are writing a perl one liner, make sure you
declare your variables with my. Don't be lazy or you will
get in to trouble later...
--
Beyond main and MY, the other packages you are
most likely to use are packages written by others.
Before we look at the syntax involved, a brief digression
as a motivation for learning this package stuff:
Amazingly, a huge number of high quality packages
are available publically for free in one nice big catalog
called CPAN. Some come with perl as standard.
Others need to be pulled in from the Internet. You can
browse and search CPAN using a web browser:
http://search.cpan.org/
More on this in a footnote**.
--
Apart from main and MY, all other packages have to be
given a name.
In a similar fashion to use of / (or \) in directory names
on hard drives, package names often include '::' to
separate logical levels of the package name. For
example, one package on CPAN is:
File::Copy
--
To use another package written by someone else,
you write something like:
use File::Copy;
this makes the File::Copy namespace available.
So you can write things like:
use File::Copy;
# Invoke File::Copy's move() procedure:
File::Copy::move("file1", "file2");
This is very explicit. There is no room for ambiguity.
But it sure is long.
Fortunately, the 'use File::Copy' statement does more
than make the namespace available. It also imports
some names right in to your main package. So you
could write:
use File::Copy;
# Invoke File::Copy's move() procedure:
move("file1", "file2");
Which names get imported in to your main package
depends on a combination of what the author of the
package decides, and what options you specify
when you use the module. For example, you can say:
use File::Copy ();
and File::Copy won't import any names in to main.
--
If you are writing more than a one liner, you should
start your scripts with:
#!/usr/bin/perl
use warnings;
use strict;
Once this is done, if you don't say where a name is
from, perl will complain that you have not provided
an explicit package name. This is a good thing, as
it forces you to be careful, and this particular form
of care will save you countless hours of frustration.
As already stated, most of the names you come up
with will refer to things that are, well, yours, so you
typically write things like:
my $foo;
so that $foo now belongs in the MY package.
If you want to refer to something from another
package, you can either specify the longhand:
$Foo::bar = 1; # set $bar from package Foo.
or introduce a shorthand version of the name
like so:
package Foo;
our $bar = 1; # set $bar from package Foo.
our $baz = 2; # set $baz from package Foo.
$_, @_, STDIN and other standard Perl variables
are exempt from 'use strict' complaints. Indeed,
you can't my these variables even if you wanted to.
--
If a my or our declaration is inside braces, Perl loses
all memory of that declaration when it encounters the
enclosing end brace:
#!/usr/bin/perl;
my $foo;
{
my $bar;
# MY namespace contains the names $foo and $bar.
}
# MY namespace no longer contains the name $bar.
--
My/our declarations stack variables on top of each other
(and unstack too) and hide other variables with the
same name:
#!/usr/bin/perl;
$foo = 1; $bar = 1;
# main package now contains a $foo and a $bar.
my $foo = 2;
# MY package now contains a $foo.
print $foo;
# Refers to MY foo i
