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