Re^2: Experimenting with Lvalue Subs

What you're saying is that providing the rvalue to the sub for validation would require the sub to be called twice. Once to obtain (a reference to) the lvalue, and the second time to allow the verification.

But if the mechanism to validate is to tie the lvalue, then a second call is going to be made anyway--to the STORE method of the tie. No different!

Except that you now have a piece of out-of-band code performing the validation, and second level of lookup to locate the appropriate tie class and a third level of lookup locate the STORE method within that.

And all this to avoid a second call in the rare case when the assignment will be undone at the end of scope?

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

Comment on Re^2: Experimenting with Lvalue Subs

Replies are listed 'Best First'.
Re^3: Experimenting with Lvalue Subs by ysth (Canon) on Jan 25, 2005 at 17:31 UTC
I'm not sure what you are arguing for or against; I'm saying the primary purpose of an :lvalue sub is to create an lvalue, and that there are many cases where the creation of the lvalue is separated in time and space from its setting. A way to specify a validation routine could certainly defer back to the original sub, with opportunity to flag it as optimizable to suppress the original call in the simplest case of (non-localized) sassign.	[reply]
Re^4: Experimenting with Lvalue Subs by demerphq (Chancellor) on Jan 25, 2005 at 19:33 UTC
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	[reply]
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]