> I hate to add a "me too" but I think this is right on. I also think that
> Nat's proposal and several other discussions overlook some stuff about
> lvalue subs. Most of the places I've seen them used really well is if
> they walk and talk like other forms:
>
> $cgi->param($var, @val); # traditional
> $cgi->param($var) = @val; # lvalue, but same thing
>
> The second one, then, just makes it more obvious what's going on. But it
> shouldn't change the behavior of the sub. In fact, these two should
> *both* be valid options for setting $var. Then the programmer can choose
> their preferred style.
And I keep pointing out that this is only one aspect of lvalue subroutines.
The point of an lvalue subroutine is not to make assignment to the return value
work, it is to make the return value an *lvalue*. That's a much more general
thing, because it allows every other type of modification to work too.
The lvalue accessor *shouldn't* be doing the assignment (what if an assignment
isn't what I want?).
The (overloaded) operator = should do the assignment. To whatever lvalue
the lvalue subroutine returns.
Or the "assignment" should be done by operator += or operator++ or
whatever mutator I'm actually applying to the returned lvalue.
Damian
