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.
In reply to Re: Analyzing opcodes of lvalue-subs...
by ikegami
in thread Analyzing opcodes of lvalue-subs...
by LanX
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |