I do see what you are saying. The call to the lvalue sub is made in order to obtain a reference to a scalar or other lvalueable entity. And it is that reference that will be localise.
But the suggestion is that the programmer can validate the assignment by tieing the lvalue. If the programmer can do this, then the code generator could too. Rather than forcing the programmer to do this for every attribite of every class, couldn't the generator do it for him under the covers? Isn't that the essence of code reuse? If the value was presented to the sub as $^_ (for example) and that was tranparently tied.
Your deferred assignment proposition OTOH is a non-starter...
So what is wrong with proxying the sub locally?
In p5 terms:
#! perl -slw use strict; { my $x = 5; sub x : lvalue { $x; } } print x; if( 1 ) { no warnings 'redefine'; our $temp; local $temp = x; local *x = sub : lvalue{ $temp }; print x; x = 123; print x; } print x; __END__ P:\test>424776 5 5 123 5
And then whatever mechanism will be in place to 'realise' the hypothetical as a real value at the end of scope, would instigate the call to the real sub (or not) as required by the logic of the code.
In reply to Re^11: Experimenting with Lvalue Subs
by BrowserUk
in thread Experimenting with Lvalue Subs
by Limbic~Region
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |