in reply to Re^4: Experimenting with Lvalue Subs
in thread Experimenting with Lvalue Subs
I don't think it's true that people simply want assignable subs. People want subs that can be used like variables, including not only placement on the left-hand side of an assignment but also in places such as pre- and postinc- and decrement.
substr( $self->seq, 20, 15 ) =~ tr/178/22x/;
It is not possible to handle the general case without requiring two different invocations, one to fetch the value, one to assign to it after determining the new value. Only the trivial case where the rvalue does not depend on the previous value of the lvalue can be handled with a single invocation.
So there are two conceptually distinct tasks involved.
I believe that handling both with a single sub is as undesirable as heavy overloading of @_'s semantics. So two separate pieces of code will be required in any case.
Once you arrive at that point, whether you correlate the subs to each other via multimethod dispatch, some closure scheme, the tieing interface, or something else completely, really makes no difference at all, assuming all of these cases will be similarly concise to express and efficient to execute.
Makeshifts last the longest.
|
|---|