in reply to A tale about accessors, lvalues and ties

There's certainly plenty of places where perl has special parsing rules (e.g. defined(&func)).

I think it'd be worth doing something, special parsing wise.

On the other hand... Maybe they should just finish and make it so $object->attr = something would work correctly and allow implementers to actually usefully check the rvalues when they're of a mind to do so. It seems silly to go part way, then stop and say: don't use this.

-Paul

Replies are listed 'Best First'.
Another approach to extend lvalues ?
by LanX (Saint) on Nov 19, 2008 at 18:12 UTC
    >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; }

    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 }

    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 ...

    Cheers LanX

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