Front page | perl.perl5.porters |
Postings from August 2010
On Aug 24, 2010, at 2:38 PM, Dave Mitchell wrote:
> On Sun, Aug 22, 2010 at 12:16:19PM -0700, Father Chrysostomos wrote:
>>> I don't understand why it's not a bug. If I do
>>>
>>> $dummy = f () || g ();
>>>
>>> people would consider it to be a bug if f () were to be called twice. Why
>>> should $x be FETCHed twice then? In fact, IMO, if $x is tied, $x in
>>> rvalue context should just be a shorthand for C<< (tied $x) -> FETCH >>.
>>
>> (Except that (tied $x)->FETCH doesn’t allow $_[0] assignment to change what the variable is tied too. :-)
>>
>> Is it really rvalue context? Consider the following examples:
>>
>> $dummy = \($x || $y);
>> $dummy = ${\($x || $y)};
>>
>> Can you come up with a way to unify the concepts such that your test would work and my two examples would continue to work (oh, and ${\($a||$b)} = $c as well)?
>>
>> In the mean time, is there any chance the first four patches could be applied?
>
> Could you re-submit the patches,
> a) with a binary backwards-compatibility entry for the old
> now-replaced-with-macro functions in mathoms.c? See
> 0d7d409d8d92b77ed7de5b74ab047eced86edfc3 for an example of this.
If we do not maintain binary compatibility in blead, then why are we maintaining binary compatibility in blead? Or are these actually for code using the Perl_ forms?
> b) Could the patches be attached to the email in a format that 'git am'
> understands, e.g. using git format-patch?
Here they are.
Please note that patch number 5 (||) is still controversial, as I’m waiting for an answer from Abigail.
BTW, the same thing happens with *{}, which returns its operand if it is already a glob.
Thread Previous
|
Thread Next