Re: Experimenting with Lvalue Subs

I wouldn't mind seeing :lvalue subs improved; but I'm not seeing clear suggestions here for how to do so (except ones that only take into account use in a scalar assignment). Any suggested improvement should

not make list-context :lvalue subs work any worse than they do now :)

specify what happens in more complicated cases:

sub foo:lvalue { ... }
(undef,foo)=bar();
bar(foo);
bar(\foo);
foo ||= bar;
bar(foo()++);
[download]

Given that, I don't see how the sub body itself can meaningfully have access to the rvalue, which IMO leads directly to TimToady's position that the sub body's job is only to return an lvalue, and that the room for improvement lies in syntax for specifying callbacks.

Comment on Re: Experimenting with Lvalue Subs Download Code

Replies are listed 'Best First'.
Re^2: Experimenting with Lvalue Subs by BrowserUk (Patriarch) on Jan 25, 2005 at 11:19 UTC
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.	[reply]
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