curiosity about the usage of my

[Luca Ferrari]

Hi,
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)?

Thanks,
Luca

[Shlomi Fish]

Hi Luca,

There isn't. The alternative to my is called "implicit scoping", where
variables spring to use upon first use, and is present as such languages as
http://en.wikipedia.org/wiki/Python_%28programming_language%29 ,
http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 and
http://en.wikipedia.org/wiki/CoffeeScript , and introduces many subtle scoping
bugs (it bit me in Ruby at least twice, and also at least twice in Python),
and as such is not considered a good idea. "my" is one of the shortest possible
ways to declare variables anyway.

See:

https://news.ycombinator.com/item?id=2864317

(not my link).

Regards,

Shlomi Fish

--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
Stop Using MSIE - http://www.shlomifish.org/no-ie/

Chuck Norris wrote a complete Perl 6 implementation in a day, but then
destroyed all evidence with his bare hands, so no‐one will know his secrets.
— http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/

Please reply to list if it's a mailing list post - http://shlom.in/reply .

[Brandon McCaig]

On Thu, May 09, 2013 at 12:15:00PM +0200, Luca Ferrari wrote:
> Hi,

Hello,

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 <bamc...@gmail.com> <bamc...@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'

[Luca Ferrari]

On Thu, May 9, 2013 at 6:22 PM, Brandon McCaig <bamc...@gmail.com> wrote:
> 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.

Thanks for the explanation, but just for the sake of calrity, I was
not asking this because of laziness, but because I believe that it is
more error prone to rely on developers to use the right scoping (my,
our, local) instead of automatically-proposing the "most-used" one.

Luca

[Octavian Rasnita]

From: "Luca Ferrari" <fluc...@infinito.it>

In that case it is not problem at all. Always use "my".

"our", "local" and "state" are much less used and if you need them, you also
know when you should use them.

Octavian