At 10:57 AM 4/20/2001, you wrote:
>Both approaches will work equally well for most general applications. You
>start to see differences when you get into more specialized applications.
>For example, if you're writing a Perl module, and you want to export
>variables using Exporter.pm, you can't use "my". "My" variables don't exist
>outside the file in which they're defined, so obviously you can't refer to
>them from any file that's going to be using your module.
The approaches are for different purposes, and use two totally different
mechanisms to do what they do. (MJD's FAQ talks about this, much more
completely and accurately. It's URL is coming up later.) The whole point
was that Perl < 5.0 only had package variables (the use vars type.) The my
keyword was added to the language because my variables (lexically scoped
private ones) behave themselves a little better.
Your point about modules and Exporter is exactly correct. You can't use
lexical (my) variables for that, and you really, really, really don't want
to use package (use vars or our or local) variables for 'everyday' use.
>The other example that comes to mind is if you ever get write CGI scripts
>that run under mod_perl's CGI engine (dang, brain cramp, what's that
>mod_perl thing called again?). Anyway, there is a really esoteric
>interaction that happens with "my" variables that causes them to hold on to
>their initial value unexpectedly. You see it sometimes in scripts that have
>a user log in--the second person to log in (and everybody thereafter) gets
>logged in as the first person who logged in, because a "my" variable held on
>to its first value. Look up "closure" in the Perl reference if you want
>more info.
>
>Anybody else want to chime in on this?
>
>Mark Nutter
Well, mod_perl is a good example of when/why to use my, but it's
enough. In mod_perl the interpreter doesn't exit between script runs, so
you can't even depend on variables being undefined when the come into
existence. Always initialize variables under mod_perl, unless you are
implementing some kind of global counter, like
$number_of_scripts_run_since_we_last_rebooted. The problem you mention
above is not a problem with my, it's a problem with the variable not being
destroyed between script runs. Perl programmers assume that when they say
my $foo; that $foo will be initialized to undef, but in this case, since
the interpreter never closed out, $foo never got out of scope, and would
not get re-created, so $foo would retain it's old value.
But the big thing about my and use vars is the difference between lexically
scoped private variables, and package ones. You want my. You need
my. Use my. There are also our and local variables (these are other ways
to talk about global package), but most of the time you don't want to use
those either.
The best FAQ I can find on this is Mark-Jason Dominus's 'Coping with
Scoping'. Read this. Read it good. In fact, check out much of his
site. A lot of it is geared toward more advanced tricks and such, but
there is some really good info. Don't worry if you don't understand all of
it, just latch on to what you can. Rome was not built in a day, and
neither was Perl, nor a Perl hacker.
http://perl.plover.com/FAQs/Namespaces.html
But making you declare variables is only part of strict. An important and
way useful one, but only one. strict's other benefits are making you make
sensible subroutine calls and not allowing symbolic references. Using
strict basically make you stay within basic rules of sanity when coding,
allowing for more readable, maintainable and understandable code. The only
code I've seen that won't work under strict are Obfuscated Perl Contest
entries and the like. If you have ever seen any of them, I think they
would server as a good reason for one to use strict in order to maintain
one's sanity and eyesight.
Bottom line, use strict and make you code run under it. If later you want
to explore stuff purely for hack value go ahead and leave it off, but
anything that will need to be depended on (production code of any sort)
really needs to be running under strict, and warnings too. If you are
learning from a book and the examples aren't using strict, warnings, or my,
throw it out. I'm serious. Then go buy one that does.
I know someone is going to say that even the Camel Book (Programming Perl)
doesn't use strict in all it's examples. It's one thing to leave out
stricts and mys in a 10-20 line example, but it's quite another when whole
500+ line programs don't have it on there. Plus, while it may note be
there, the examples in the Camel Book will run under it, if only after you
add proper my declarations. Few examples out of Perl for Dummies and Learn
Perl in 21 Days (both not recommended) will work.
Par usual, check out the docs for more info. strict and vars docs,
perlfunc for my, our, and local.
Sorry to go on and on about this, I'll get down off my soapbox now. But I
really think this is important. It can save you hours of hair-ripping and
monitor-trashing aggravation. It can help you write better, more reliable
code.
Thank you for (an inordinate amount of) your time,
Sean.
