There's more than one way to do things | |
PerlMonks |
Re: Undocumented join() feature, now defunct? (optimization)by tye (Sage) |
on Oct 30, 2014 at 00:48 UTC ( [id://1105574]=note: print w/replies, xml ) | Need Help?? |
My expectation was that the EXPR would be evaluated once and the invariant result used between every element of the LIST. Then you should probably adjust (and loosen) your expectations about exactly how much optimization has or hasn't been done to a particular feature in a particular build of Perl. If you manage to construct code that behaves differently depending on whether the implementation of some feature (especially one that uses the value more than once) evaluates the value once or twice, then you've written code that is likely to break when an optimization gets done. If I had reason to pass a magical scalar that changes values to join, then I'd tell Perl to fix the value first via:
and the wording looks the be the same for for all versions Yeah, people don't usually update the documentation of the basic functionality when an optimization is made. In your mind, one of these two has to be broken?
Now if I go and optimize out the copying of most of @_ into @vals, that breaks something too? Or are both of those broken because they don't avoid copying from @_? Next you'll tell me that join2 is broken because it evaluates $sep even if when @vals is empty and so $sep isn't actually used. IMO, none of these are bugs. They are implementation details that reasonably should be expected to change at any time when some bug gets fixed, some code gets optimized, some code gets refactored, etc. Making scalars that change every time you look at them is weird stuff. You have to put up with weird things happening and take extra care when you do stuff like that. - tye
In Section
Seekers of Perl Wisdom
|
|