Nathan Wiger writes:
> Well, this argument makes more sense. However, I still have to disagree.
> In fact, I think the opposite: ALL subs *should* be lvaluable by
> default. Here's why.
I think I failed to explain Damian's use of the word 'dangerous'.
my $var;
sub routine {
$var;
}
This, by virtue of rvalue subs being default, keeps the lexical $var
private. Damian's big on privacy.
Your change would make privacy violation *automatic*.
That's dangerous.
> Might look weird at first, but it's not. It's just like any other
> assignment. This surely doesn't look weird:
>
> @array = ($r->{func}) = split /:/, <PASSWD>;
>
> And it works just fine in default Perl 5 with no special keywords.
No it doesn't. $r->{func} holds a scalar. split will return the
number of fields, not the data. This is irrelevant to your thesis,
though.
> lvalue subs are worth a lot more than just simple data accessor
> functions. I don't see why we should force-relegate them to a background
> role by requiring an :lvalue constraint that most people won't
> understand how to use correctly.
Now you're into rhetoric.
(1) It's not a background role.
(2) Changing variables in the subroutine's scope is a BIG THING, and
ought to be explicitly enabled, rather than explicitly disabled.
(3) :lvalue is hardly rocket science. You drastically overstate its
complexity.
Nat
