groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: Problem overloading bracket operator with CompileStatic
Date Sun, 27 Dec 2015 18:51:11 GMT
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) 

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

View raw message