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 |