Bryan C. Warnock wrote:
> Oh, wait, commas are now implicitly parenthesized, so that
> (my $a, $b, $c) = @_;
> can be written as
> my $a, $b, $c = @_;
>
Oh! I never said commas are implicitly parenthesized! That was other
proposal. I don't think it works, because
$a, $b, $c = @_; # $c gets 10 for @_=(1..10)
mean a different thing that
my $a, $b, $c = @_; # $c gets 3 for @_=(1..10)
The last code should behave as
my $a, $b, ($c = @_);
ie. $a, $b and $c are lexicals, and @_ is assigned to $c in scalar context.
I'm sure I posted this example a while ago.
> That's going to affect some compound expressions, but those can easily be
> fixed by liberal uses of the 'scalar' operator, er, function, er, term.
> Oh, wait. That also doesn't behave quite right. That can also be
tweaked,
> I'm sure.
>
I'm not saying anything about changing `scalar'. It DWIMs all the time.
That's certainly not the case with `my'.
> But what does that give you?
`my' DWIMs.
> You've now taken several existing behaviors of the language and completely
> changed it for no *net* improvement to the language. (Okay, that may be
> subjective, but feel free to argue how what you've added significantly
> outweighs a) what you've changed, and b) the fact that you changed it.)
>
I know this is bad for who already writes Perl code. But it would be very
good for who learns Perl and doesn't understand exactly when he should and
when he should not put parenthesis around `my's list of variables.
> - you do a complete brain drain before changing existing functionality,
and
> that change had better provide a huge net improvement to the product,
I think that's why we discuss it here.
> - you don't make any of these decisions arbitrarily.
That's why we argue about it. It's not about changing something just for the
fun of it. We must see where it's better, where it's not, if we would pay
the price for changing it, if it's worth it. I'm not proposing it because I
like changes, but I also don't the not DWIMness of some things of Perl.
- Branden
