|more useful options|
Re^8: Experimenting with Lvalue Subs (trade-offs)by tye (Sage)
|on Jan 25, 2005 at 09:53 UTC||Need Help??|
Yes, for the rare cases, it increases the number of calls. For the common cases, it can reduce the number of calls and complexity.
But this brings me back to my original suggestion, which was to leave :lvalue alone and provide :sassign (s=scalar) and :aassign (a=array since both 'list' and 'left' start with 'l') alternatives that make the easy stuff easy (and faster) but may not support the rare stuff (and, obviously, wouldn't support flipping between scalar and list contexts at run time).
Though you could still support general lvalue emulation for :sassign. For example, when an :sassign is used in an lvalue context other than a simple assignment (and perhaps a few other optimized cases), create a single closure that basicly curries the 'get' part of the method call and give this closure magic which means that assignments to it call it with the value to be assigned as the only parameter.1
So authors can choose to write 'set' routines in one piece instead of two while allowing their users to use assignment statements while Perl can automatically create a light-weight 'tied' closure only if the user uses the lvalue in a more complicated fashion.
But those who prefer to write 'set' methods in two pieces can optimize for the complex cases using :lvalue.
1 I don't know if such makes sense for :aassign cases in Perl6 (it wouldn't in Perl5 because lists get flattened and supporting flattening of :aassign looks like a mine field to me).