On Tue, 28 Sep 2004, Errin Larsen wrote:
> On Tue, 28 Sep 2004 18:51:12 +0800, Edward Wijaya
> <[EMAIL PROTECTED]> wrote:
>
> > use vars qw($f);
>
> The above is good, but is now obsolete.
That is debatable.
Gather round, and listen to the story of a log handling utility
written in perl, and a frustrated user. He's not a perl programmer,
he's a Solaris sysadmin. For him, perl is just a tool, just another
language. And the version of perl shipped with his Solaris is
5.005_03.
He is disinclined to build and install a new version of perl just
to support a single tool. After all, he doesn't have to build
new versions of awk, or new versions of C. Why should perl be any
different?
Trouble is, the author of this tool didn't agree. He had used
our variables instead of my. Which, of course, don't work in
5.005_03. The user was quite prepared to ditch the tool altogether
and find another because it didn't Just Work. I suggested that he
go through it replacing our with my and lo and behold, it worked.
The moral of this story is that even if you have the latest and
greatest perl, you shouldn't use the latest and greatest features
unless you absolutely must. Because if you do you will severely
limit who will use your code. our in particular is really only a
convenience, saving a few key strokes at most. So don't use it.
Ever.
I'll buy a crate of beer for the first person who can show me some
real-world code which absolutely requires our and can't be
re-written to use my <update>or use vars (cos I meant to say that
originally as well)</update>.
<http://www.perlmonks.com/index.pl?node_id=393423>
The latest & greatest is only worth using if:
* it really does offer you something you need
* it really does offer you something that wasn't available before
* you really don't have to worry about portability
* there really aren't downsides to using it
For most people, in most cases, one or more of these won't be true.
It's worth it to be aware of the downsides of using a modern feature
like `our`, and to be confident that it really does make more sense to
use it over some older approach. It may be that the new ways really are
better -- I'm certainly not against progressing the language -- but if a
new feature breaks otherwise good code, is it worthwhile?
--
Chris Devers
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
