Re^4: Experimenting with Lvalue Subs

the primary purpose of an :lvalue sub is to create an lvalue

Sure, but what this thread is about is that most what people want in an assignable method isnt the same thing as an lvalue. The fact that 'lvalue' has been used in this thread is an indication of the problem, people want method calls that look like assignment and they think lvalue's are the way to get them. We need a different type of assignable method instead. While what lvalue subs are sounds like a nice thing it just isnt what most folks want when they want to write a getter/setter method. And I'm unconvinced that callback save the day at all. As BrowserUk pointed out we may make no direct mapping between the assigned value and any given memory location, so a callback from such a memory location just can't do what we want.

---
demerphq

Comment on Re^4: Experimenting with Lvalue Subs

Replies are listed 'Best First'.
Re^5: Experimenting with Lvalue Subs by Aristotle (Chancellor) on Jan 25, 2005 at 21:43 UTC
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/;` [download] 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.	[reply] [d/l]

Replies are listed 'Best First'.

Re^5: Experimenting with Lvalue Subs
by Aristotle (Chancellor) on Jan 25, 2005 at 21:43 UTC

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/;
[download]

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.

[reply]
[d/l]