Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.apache.org
Subject: Re: Method resolution pondering
To: dev@groovy.apache.org
References: <CAMbkE7SSj=O=R5sZWe48wDn_=8d+84_5Zkyj8oc_+Mn_Wz_L0Q@mail.gmail.com>
From: Jochen Theodorou <blackdrag@gmx.org>
Message-ID: <57C177F8.7090003@gmx.org>
Date: Sat, 27 Aug 2016 13:22:32 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <CAMbkE7SSj=O=R5sZWe48wDn_=8d+84_5Zkyj8oc_+Mn_Wz_L0Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Sat, 27 Aug 2016 11:22:46 -0000

On 27.08.2016 12:22, Paul King wrote:
> I am just wondering what people's thoughts are on the different
> approaches different parts of Groovy take for method resolution when
> multiple methods are matched.
>
> Given this code:
>
>    import groovy.transform.CompileStatic
>
>    interface FooA {}
>    interface FooB {}
>    class FooAB implements FooA, FooB {}
>    @CompileStatic
>    class TestGroovy {
>      static void test() { println new TestGroovy().foo(new FooAB()) }
>      def foo(FooB x) { 43 }
>      def foo(FooA x) { 42 }
>    }
>
>    TestGroovy.test()
>
> The output will be 42 because FooA comes before FooB in the implements
> clause for FooAB.

I think we should orientate us at Java for this... and in Java I would 
expect this to fail compilation

> If we leave off the @CompileStatic, their will be a runtime exception:
>
>    groovy.lang.GroovyRuntimeException: Ambiguous method overloading for
> method TestGroovy#foo

that I expect

> Given this trait example:
>
>    trait BarA { def bar() { println 42 } }
>    trait BarB { def bar() { println 43 } }
>    class BarAB implements BarA, BarB {}
>    new BarAB().bar()
>
> the output will be 43 because BarB comes last in the implements clause.

that is not because of method resolution, that is because of how the 
traits are mapped to BarAB. BarAB has in fact only one bar() method. So 
I do not really see a problem with this one


bye Jochen