On Thu, Jan 27, 2011 at 11:17:18AM +0000, Ed Avis wrote: > Abigail <abigail <at> abigail.be> writes: > > >>>>> $ perl -E '$a = $b = "abc100"; 0 + $b; say $a; say $b; > >>>>> $a ++; $b ++; say $a; say $b' > > >>just evaluating the expression ($b + 0) in some other code, even if you > >>do not assign the result to $b or try to change $b in any way, has the > >>unexpected side-effect of changing the value stored in $b. > > >Not changing the value stored in $b means that > > > > my ($a) = /([0-9]+)/; > > @foo = map {$_ + $a} @bar; > > > >becomes more expensive, and $a will need to be converted from string to > >integer for each element of @bar, instead of doing it once and caching > >the result. > > I see. Personally, I'd take 'correct, but slightly slower' over 'a bit faster > in some cases, with surprising edge cases' any day. That's why you should never use floating point numbers, right? ;-) > have it both ways? The numeric value could be cached in the scalar and used > next time, but without flipping the switch to mark the scalar as numeric. Then > later numeric context uses would be fast, but the value would not mysteriously > change. > > I have only a loose idea of Perl internals so please forgive my ignorance here; > from a user's point of view not changing a variable just because it was *read* > in an arithmetic expression is definitely the right thing to do, but I am > uncertain of the practicalities of doing so in the perl interpreter. That would probably mean we have to use a bit (or two, or three, if we want to use the same trick for floats and strings) in the very limited supply of bits reserved in the SV structure, for a case that's only seldom useful. AbigailThread Previous | Thread Next