groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Method resolution pondering
Date Sat, 27 Aug 2016 10:22:01 GMT
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.

If we leave off the @CompileStatic, their will be a runtime exception:

  groovy.lang.GroovyRuntimeException: Ambiguous method overloading for
method TestGroovy#foo

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.

It seems unfortunate that we have three differing ways to handle
resolution and I am wondering what appetite we might have for trying
to consolidate the approaches in some future version of Groovy.

Cheers, Paul.

Mime
View raw message