Nathan Wiger wrote:
>
> I wouldn't be so hasty to withdraw from the my binding argument. There's
> many uses of "my" that are required even with the "use scope" pragma (at
> least as I described it in RFC 64, but feel free to point it out if I
> missed an application). I think there's some good chugging on the my
> binding concept going on, so let's not kill it quite yet.
>
OK. I'll keep discussing it, although I'm now positioning me FOR `use scope'
as I described in my last postings, which is a little different than what's
proposed on RFC 64 and doesn't suffer of some of the AAAD that RFC 64 (ie.
`our' outside the scope may change the scope of a variable in a distant
block).
You're actually right saying that even with `scope', `my' would be useful in
some circumstances, but as it would be less situations, I don't mind if it
keeps how it is, I probably won't use it too much to bother changing it.
> To rehash, all this discussion should involve is the possibility of
> making "my" swallow its list args:
>
> my $x, $y, $z; # same as my($x, $y, $z)
>
> That's it. No changing the way lists and , and = work in Perl. If you
> want to use split you still have to say:
>
> my($name, $passwd) = split ':';
>
Well said! No changing `,' and `=', only `my' (and possibly `local' and
`our'). Changing `,' and `=' has too much side effects to be considered.
> FOR
> ---
> 1. It becomes more consistent with other Perl functions
>
Jarkko Hietaniemi wrote:
> my is not a function. It is a declaration. Functions take arguments
> and return values. my does not. It is language construct like if.
> Unless, of course, you claim that if is a function, too. That
> ways lies LISP. I actually like LISP, but why reinvent it...?
Well, let's rephase it:
1. `my' becomes more consistent with other Perl thingys
that get lists as arguments, as Perl functions, for
example.
> AGAINST
> -------
>
> 2. In certain situations, such as trying to declare a variable
> inline as a list arg, it requires an extra set of ()'s.
> For example:
>
> tie my $shoe, $string;
>
> no longer works as written, since my will gobble the vars
> and tie will complain "not enough arguments".
>
> Once point of consideration: What if my() returned its
> argument list verbatim, similar to how bless() does
> double-duty?
>
Actually, that code above returns two arguments, like
tie my($shoe, $string);
which is the same as
my $shoe; my $string; tie $shoe, $string;
But that's different of what it (probably) should be:
tie my($shoe), $string;
Well, the workaround is so simple, just put parenthesis around. It's the
same as what you'd do if you were using the result of a function as
parameters to another function, so it means (even knowing that `my' isn't a
function) consistency with other Perl thingys.
> 3. This is a change which will break existing Perl code.
>
It's good to say: Not always. my( $x, $y, $z ) won't break. So won't my $x =
$y;. Only what will break is the using of my in the middle of the arglist of
a function, basically. And that's easily translatable by putting parenthesis
around `my's variables, what also increases readability.
Think about it, the change isn't really big. The only differences are the
necessary parenthesis on usage of `my' in the middle of a list of arguments
and the fact of `my $a, $b, $c;' DWIMs, what is a big win, IMHO. Beginners
would know they can use `my' the same way they use every function in Perl,
what also makes Perl a little easier to use. (Note I didn't say `every
*other* function', I *know* `my' isn't one.)
- Branden
