On Sun, 18 Mar 2001 nick@ing-simmons.net wrote: > <abigail@foad.org> writes: > >On Mon, Mar 12, 2001 at 11:59:24AM +0000, Nick Ing-Simmons wrote: > >> > > >> >Is this a bug or not? > >> > >> It cannot be - changing either is bound to break something. > >> > >> >Is there a way to fix this? > >> > >> Not without breaking scripts which rely on the behaviour. > > > > > >I've a bit of a problem with that reasoning. That would mean you can > >never, ever fix a bug, because there's bound to break something. > > It is a way of defining what can be a bug. If the behaviour is useful > and likely to be used it isn't a bug it is a feature. > > > > print 'foo'=~/(.*)/ && $1, 'bar'=~/(.*)/ && $1, "\n"; > > > print 'foo'=~/(.*)/ && "$1", 'bar'=~/(.*)/ && "$1", "\n"; > > In this case I assume that there is an existing body > of code that expects $1 to to be the last value matched, so that making a copy > as it is passed to print (or subs in general) would break that code at least. > And the second line shows that there is an easy way to get the copy if that > is what you want. If there is, then that code is wrong. Code should never depend upon the order of evaluation within a single statement. Even when order of execution within a statement is defined by the language, it is a bad habit to count on it. Remember, Perl not only tries to be portable among machines, but also among the minds of programmers with different backgrounds. This principle is often mentioned by the community, but they usually call it the Principle of Least Surprise. While many things in Perl differ from whatever language a programmer may have experienced, code that breaks the very tenets of good style in other languages may confound a maintenance programmer - or, perhaps more importantly, may confound someone who is translating Perl source to another language (in particular, I'm thinking of C) in which order of execution within a statement is not necessarily defined. It could be worked around in translation, but that could be a pain. Chris