> > Ooops! The author didn't use :lvalue. So even though this makes perfect
> > sense to be able to do, since the author forgot to use :lvalue, you lose
> > a really cool syntactic tool. This seems backwards.
>
> Seems right to me. I'd rather assignment to a function work on
> purpose rather than on accident. If lvalue subs are the default, then
> they "accidently" work where maybe they shouldn't. Whether a sub
> should be lvaluable should be a conscious decision made by the
> subroutine author.
See, I don't see it as that big a deal, especially not if lvalue and
rvalue subs work identically.
For example, here's code that works identically in Perl:
@array = @array, func; # ok
push @array, func; # same thing
Now, maybe someone would argue one is "more correct" or "better style"
than the other. However, TMTOWTDI.
That's all lvalue subs are. Remember, just because something's an lvalue
DOESN'T mean 2 key things:
1. It's working like a variable
2. It's all the way to the left
Please look at this example again:
@array = $r->func((split /:/, <PASSWD>)); # ok
@array = ($r->func) = split /:/, <PASSWD>; # same thing
All that is to me is TMTOWTDI.
Now, we can argue forever that the second one is a bad STYLE. I would
probably agree. HOWEVER, we shouldn't be dictating style to the user,
which is all :lvalue does if lvalue and rvalue subs work identically.
I'm actually quite surprised that people are disagreeing with me on this
one. There's a lot of times when you could use cascading lvalue subs to
make things easier:
@result = ($first, $second, $r->fix_the_rest) = split /:/, <PASSWD>;
This would be at least 2 lines without a cascading lvalue sub, and less
clear:
($first, $second, @rest) = split /:/, <PASSWD>;
@result = ($first, $second, $r->fix_the_rest(@rest));
As an advanced Perl user, I want to be able to exploit such constructs
at will. I don't want others deciding programming style for me.
-Nate
