On 27.12.2015 17:54, Dinko Srkoč wrote:
[...]
Umm ... Jochen, are you sure this is right? I'm rather convinced that
this should work in both Java (using interfaces instead of traits) and
Scala ... and by extension, I would be inclined to call the above
behaviour a bug. Being statically compiled or not, isn't this the case
of dynamic dispatch, which should work in any OO language?
on second view... wow... sorry Byron and thanks Dinko for pointing that
out. I somehow did see quite different code. So let's take it slow
trait SimpleMap<K, V> {
abstract V getAt(K k)
}
class Foo implements SimpleMap<String, String> {
String getAt(String k) {return "bar"}
}
if the getAt in Foo is not overriding the abstract getAt in SimpleMap,
then this should not even compile. Assuming it does compile, the methods
should be overridden, thus it should work. And even if getAt(Object) is
used by the static compiler, it should work...
But... and here is the problem... There is a DGM getAt(String)
(http://docs.groovy-lang.org/latest/html/groovy-jdk/java/lang/Object.html#getAt%28java.lang.String%29)
as well, which is a shortcut for property access. And now comes part of
the argumentation I had in the previous mail. The compiler sees onlny
the type SimpleMap, does knows only getAt(Object) (declared on
SimpleMap) and getAt(String) (from DGM). Since the String version is the
most fitting one and since there is no calling mechanism for subclasses
to override a DGM methods in a virtual way as it exists in dynamic
Groovy, the compiler will cause the effect of inheritance to be ignored.
That we are looking at a trait here is actually only of secondary
importance. It could have been an interface and we should face the same
problem (if not, that would be actually a bug)
This is a limitation of the static compiler atm.
bye Jochen
