On Thu, May 09, 2013 at 12:15:00PM +0200, Luca Ferrari wrote: > Hi, Hello,
> the usage of "my" to scope variables is a good habit, and under
> "strict" is almost a need. But just today I realized that
> having to write "my" in front of each block of variables does
> not seem to me a perl-ish way of doing things: it requires
> extra effort to a quite simple task (variable declaration). Is
> there any ongoing effort to make "my" the default behavior (for
> example in Perl 6, that I'm totally unaware of)?
I think that it makes sense to make it explicit. my() and our()
let you know when a variable comes into existence. They're also
quite terse as it is. It's really not a lot of work. I'd rather
know when I'm bringing a variable into the world, and have the
compiler yell at me if that variable already exists in this scope
because it means I'm making a mistake; I'd rather catch that at
compile-time then maybe catch it at run-time.
# Contrived subroutine...
sub foo {
$foo = $_[0] * $_[1];
$bar = $foo ** $_[2];
return $foo == 0 ? undef : $bar / $foo;
}
So assuming this hypothetical Perl where lexical variables just
pop into existence, are $foo and $bar lexical variables local to
the sub, closures from an outer sub, lexicals at file scope, or
are they package variables? What if the code around them changes?
Let's say 300 lines up (several screens away) you introduce a new
$foo at the file scope. Does that change the meaning of sub foo?
With an explicit my() declaration it wouldn't. Without it, I think
it would have to. That's a dangerous world to live in. I think
my() and our() are awesome the way they work now.
(Interestingly the perldoc explains that our doesn't necessarily
create a variable, but it associates the name within a lexical
scope with the package; for intents of this discussion I think
that's just semantics)
In any case, for backwards compatability purposes it probably
isn't possible to change this for Perl 5. I don't think you'd
want to change it either.
/nitpick
I always find it annoying when people declare laziness as a good
trait for programmers. I disagree. Lazy means not doing something
because it takes effort, even if it's a good or correct thing.
It's a good trait for programmers to avoid waste, but not if it
comes at the expense of reliability, security, or robustness.
Using my() and our() takes very little effort and is well worth
the investment.
/rant
Regards,
--
Brandon McCaig <bamcc...@gmail.com> <bamcc...@castopulence.org>
Castopulence Software <https://www.castopulence.org/>
Blog <http://www.bamccaig.com/>
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'
signature.asc
Description: Digital signature
