On Sat, 12 Oct 2002, Larry Wall wrote:
> On Sat, 5 Oct 2002, John Williams wrote:
> : Personally, I hope they look like attributes.
>
> They will, outside the class anyway. Inside it's $.foo.
>
> : But if they do, the perl5
> : lvalue subs are not the way to do it. Why? Because an lvalue sub returns
> : a lvalue which get set _after_ the sub returns. At that point it is too
> : late for the sub to do anything useful with the new value.
>
> Lvalue methods will have some kind of optional property which specifies
> a closure to execute after the modification happens.
>
> method foo {
> my $handle = find_database("random criteria");
> return $handle.fetch();
>
> WRITE {
> $handle.store(shift);
> }
> }
>
> Or some such. Note how the internal block allows capture of the $handle from
> the original closure. (A READ closure was also discussed in Zurich.)
That looks good. I was actually imagining some sort of tie-like routine
which would be called whenever the variable was accessed.
method foo is accessor ($stuff_i_might_need_to_know, $new_value) {
if exists($new_value) {
...
$.foo = $new_value;
}
...
return $.foo;
}
lvalue methods still seem to work in reverse to me though. If I say
$x = $object.foo = $y;
then first an lvalue accessor returns an object to receive the value of
$y. Next the write (oh by the way...) closure is called. Finally the
value of $y is passed on to $x, but its too late for foo to change its
mind about what its own value will be if something in write{} caused the
collapse of its quantum state.
An accessor like the above could return a different value than it was
given, which would admittedly be an odd thing to do, but perl users being
what they are, someone would think of a reason to do it.
By the way, which apocalypse will describe how properties work?
It seems like they will need some similar way of "taking control" when a
variable or value (or method or class or whatever) is accessed.
~ John Williams
