Front page | perl.perl5.porters |
Postings from March 2001
On Sun, Mar 18, 2001 at 04:19:47PM +0000, 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.
How does p5p define "useful" and "likely to be used"?
> > > 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.
In the case of $1, stringifying it doesn't harm it. But the same
behaviour happens with all scalar variables. Including references. Whose
stringification isn't reversable.
As for this specific case, I don't find it at all reasonable to assume
there's a body of code following it, assuming $1 to be anything. However,
that's irrelevant, as it's not the last $1 that's causing the problem -
it's the first $1 which isn't what one would expect it to be.
It boils down to, should && and || return aliases, or values? If it's useful
and likely to be used, could you point out some code that's using the fact
&& returns an alias, and would break if it returns a value?
Furthermore, if && is supposed to return an alias, shouldn't the following
at least parse, and either assign 1 to $bar or give a runtime error?
($foo && $bar) = 1;
Abigail