Just on what you've written here, I think
is not a great idea as it gives you many of the problems of direct hash access. It seems to me that creating individual Lvalue methods for each field in you object gives you run time checking without having to write a key_ok() sub and it also gives you overridability.$obj->get_set( 'name' ) = 'Limbic';
seem much nicer to me (although I prefer fields to have an initial capital letter).$obj->name = 'Limbic';
As for getting the rvalue, it's possible but it's not pretty! Basically you use a tied scalar as the lvalue and then when it gets assigned into, you can see the rvalue and you can do whatever tricks you like. In my own class and also in C::A::L when the tied object is written to or read from it just calls the setter or getter method respectively. This gives you full overridability, just override the default setter method.
There's lots of overhead but you can do cool stuff like a two-way hash, for example:
here we have overridden setPositions, getPositions, setPeople and getPeople so that each of the setters updates 2 hashes internally, 1 mapping from People to Positions and the other mapping the opposite direction. The getters just read from the relevant hash.$dept->Positions("manager") = "bill"; print $dept->People("bill")."\n"; # manager
2005-01-29 Janitored by Arunbear - fixed hard-coded pm link, as per Monastery guidelines
In reply to Re: Experimenting with Lvalue Subs
by fergal
in thread Experimenting with Lvalue Subs
by Limbic~Region
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |