>It seems silly to go part way, then stop and say: don't use this.

Well it's "experimental" and adding new features into Perl 5 is for sure no fun. Dependencies across the code seem to form a gordian knot. I read once the main argument for Perl 6 is that Perl 5 is at the limits of extendibility. Another faster tie mechanism might be a hell of a work...

But maybe there is another approach how to extend lvalue subs. I just realised that lvalue-subs are not limited on returning scalars, they can also return another lvalue-sub at the end:

sub normal :lvalue {
   proxy();
}
sub proxy :lvalue  {
   $anyscalar;
}
[download]

it might be interesting to see how this is realised on the level of op-codes and if proxy() could be realised externally, maybe as a c function!

AFAIK it's possible with XS to call non-lvalue c functions from within perl. Maybe it's possible to write a module which realises a lvalue function named proxy() which takes coderefs for a STORE and FETCH routine and calls them internally on the to be wrapped variable.

sub normal :lvalue {
   proxy(\&store,\&fetch,\$var); # imported function
}
[download]

This interface wouldn't change anything in the code of the p5porters, but could be much faster than tie is!

Maybe someone who knows more about opcodes and c extension might comment on this idea ...

UPDATE: The discussion continues here Analyzing opcodes of lvalue-subs...