If something is being assigned to 'path', then I'd know I need the lvalue -- and return something likep->{_path}
So if someone want to read path, they would get a simple, direct reference (no tied var overhead), but if they wrote to it, it needs to store the new value, and clear the internal value for _url so it can be re-composed.$p->{tied_path} sub callback_for_STORE_into_tied_path { my $p=shift; my $newvalue; $p->{_path}=$newvalue; $p->{_url}=undef; ... $p->{_path}; } ...later...in sub url(;$) { my $p=shift; $p->compose_url_from_parts() unless defined $p->{_url}; $p->{_url} }
At no point should I need to return a constant -- just a choice between the actual var in the hash, or a tied var.
If I knew the lvalue-context, is there a reason why that wouldn't work?
In reply to Re^8: can sub check context for lvalue vs rvalue context?
by perl-diddler
in thread can sub check context for lvalue vs rvalue context?
by perl-diddler
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |