develooper Front page | perl.perl5.porters | Postings from December 2010

Re: [perl #71286] overload (2 bugs): fallback/nomethod failures withheterogeneous operands

Thread Previous | Thread Next
From:
Dave Mitchell
Date:
December 3, 2010 04:42
Subject:
Re: [perl #71286] overload (2 bugs): fallback/nomethod failures withheterogeneous operands
Message ID:
20101203124219.GE2685@iabyn.com
On Mon, Dec 14, 2009 at 10:54:25PM -0800, Michael Breen wrote:
> These two bugs are distinct but related: the second one was exposed by some of the test code added for the first.
> The patch (to follow) therefore fixes both.

Sorry that we've collectively failed to do anything with your patch for
nearly a year. I've finally had a chance to look at it, and have now
applied it with the commit shown below.

> Note: The documentation for overload is ambiguous on the correct
> mechanics and precedence of fallback and nomethod where there are two
> overloaded operands.
> This is not the only problem with the documentation that I've found, and
> it is probably best fixed as part of a more general reorganization (as
> the man page itself says, "This document is confusing...  It would seem
> a total rewrite is needed.").
> Therefore I propose to write a separate bug report for the
> documentation, once this fix is accepted.

Have we put you off completely, or are you still willing to do this?
Having spent a few hours getting my head round this patch and trying to
understand the issue, I agree that the docs are as clear as mud on
fallback and nomethod. I think what would be particularly helpful would be
two tables, one for unary and one for binary ops, showing the order of
tests that select which method resolution.

> Bug 2
> =====
> With two overloaded operands of different types, neither of which
> defines a 'nomethod' method, the decision on whether to fall back to the
> default implemention of the operator is determined solely by the second
> operand.
> 
> While this is even more obviously wrong than the first bug, the correct
> behaviour may be less clear:
> should the fallback occur if either operand has fallback=1?
> No: any other value for fallback is a statement that a numified or
> stringified version of that operand does not produce sensible results
> with the standard operators.
> Logically, neither operand can blindly overrule the other in this
> respect (except by providing a 'nomethod' - but in that case the
> nomethod can check the type of the other operand before deciding what to
> do).
> Therefore the fix must be to make fallback to the default operators
> dependent on both operands having fallback=1.

I had to think for a while to decide whether this should fallback with
*either* of *both* operands having fallback=1, and eventually decided I
agreed with you.

Here's the commit message - let me know if its not an accurate summary of
the issue!

commit bf5522a13a381257966e7ed6b731195a873b153e
Author:     Michael Breen <perl@mbreen.com>
AuthorDate: Tue Nov 30 17:48:50 2010 +0000
Commit:     David Mitchell <davem@iabyn.com>
CommitDate: Fri Dec 3 12:16:06 2010 +0000

    [perl #71286] fallback/nomethod failures
    
    This fixes two bugs related to overload and fallback on binary ops.
    
    First, if *either* of the args has a 'nomethod', this will now be used;
    previously the RH nomethod was ignored if the LH arg had fallback value
    of undef or 1.
    
    Second, if neither arg has a 'nomethod', then the fallback to the built-in
    op will now only occur if *both* args have fallback => 1; previously it
    would do so if the *RHS* had fallback => 1. Clearly the old behaviour was
    wrong, but there were two ways to fix this: (a) *both* args have fallback
    => 1; (b) *either* arg has fallback=> 1. It could be argued either way,
    but the the choice of 'both' was that classes that hadn't set 'fallback =>
    1' were implicitly implying that their objects aren't suitable for
    fallback, regardless of the presence of conversion methods.

M       gv.c
M       lib/overload.t


-- 
Thank God I'm an atheist.....

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About