in reply to Analyzing opcodes of lvalue-subs...

so even on the level of the opcodes the lvaluesub has no chance to know which value will be assigned to the variable he returns ... Correct?

Correct. sassign (in this case) will do the assignment, and only after the sub has been called.

The value to assign has already been calculated and awaits on the stack, but that doesn't help because the lvalue sub might have been called as foo() += 5; or (foo(), bar()) = (6, 7);.

call the lvalue-sub, which returns a var by reference

(My understanding in this area is limited. Take with a grain of salt.)

Perl doesn't return SVs, it returns pointers to SVs. So technically, values are always returned by reference in Perl. The point of :lvalue is not to cause the sub to return by reference. Flags passed to entersub indicate it's being called as an lvalue. The only thing entersub does with it is tell the last expression evaluated in the sub that's it's called as an lvalue.

Most expressions already return lvalues. The effect of the flag is usually to create variables that don't already exist. For example, sub f :lvalue { $h{x} } will create both $h (rv2hv) and $h{x} (helem)

If the lvalue flag wasn't provided, it wouldn't create those variables, so it would return a read-only undef instead of a writable value.

Replies are listed 'Best First'.
Re^2: Analyzing opcodes of lvalue-subs...
by LanX (Saint) on Nov 21, 2008 at 11:52 UTC
    ikegami & dave, thanks for your very insightful help! 8 )

    it's clear now, that an extension of perl's inner mechanism of lvalue (which is a general one not only restricted to subs) can only be extended by tieing a callback function to the variable.

    reading perlguts I found some slots to add external "magic"-properties to variables.

    "The PERL_MAGIC_ext and PERL_MAGIC_uvar magic types are defined specifically for use by extensions and will not be used by perl itself."

    IMHO this should be much faster than with classical oo-tie, but I'm not sure if there are other extension (*) relying on this mechanism which would interfere and break a "Turbo-Tie" solution ...

    Cheers Rolf

    UPDATES:

    * probably DBI ???