Front page | perl.perl5.porters |
Postings from October 2017
On Sun, Oct 29, 2017 at 11:23:13AM +0100, demerphq wrote:
> I've tried very hard to be bug-for-bug compatible with existing behaviour.
> See for example this code comment in pp_multiconcat()!
>
> /* special-case $tied .= $tied.
> *
> * For something like
> * sub FETCH { $i++ }
> * then
> * $tied .= $tied . $tied . $tied;
> * will STORE "4123"
> * while
> * $tied .= $tied
> * will STORE "12"
> *
> * i.e. for a single mutator concat, the LHS is
> * retrieved first; in all other cases it is
> * retrieved last. Whether this is sane behaviour
> * is open to debate; but for now, multiconcat (as
> * it is an optimisation) tries to reproduce
> * existing behaviour.
>
> But no doubt there will be a whole bunch of things I didn't anticipate,
> and I look forward to the inevitable slew of BBC tickets.
>
>
> But wouldn't we consider this a bug we should fix?
>
> $x.= EXPR;
>
> Should be the same as
>
> $x = $x . EXPR;
From perlop:
Assignment operators work as in C. That is,
$x += 2;
is equivalent to
$x = $x + 2;
although without duplicating any side effects that dereferencing the
lvalue might trigger, such as from C<tie()>. Other assignment
operators work similarly.
So they're not quite the same. There are also two conceptually different
activities: retrieving the lvalue or rvalue, and evaluating it. For
example a tied array could return overloaded objects. So in
$tied[0] = $tied[0] . $tied[1];
$tied[0] .= $tied[1];
$tied[0] .= $tied[1] . $tied[2];
trying to determine the exact number and order of FETCH(), '.'-overload
and '.='-overload calls is somewhat non-obvious.
--
Dave's first rule of Opera:
If something needs saying, say it: don't warble it.
Thread Previous
|
Thread Next