groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Byron Foster <by...@base2.cc>
Subject Re: Problem overloading bracket operator with CompileStatic
Date Mon, 28 Dec 2015 01:42:57 GMT

> On 2015-12-27, at 11:51 , Jochen Theodorou <blackdrag@gmx.org> wrote:
> 
>> 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.

Thanks Jochen and Dinko for taking a detailed look at this.  The behavior does work as expected
if calling the .getAt method directly and avoiding the [] operator in the go() method. No
big loss, I was just partial to the slicker syntax of using the brackets, and it seemed appropriate
since it behaves like a Map.

You can’t tell from my example, but the stack trace points to the go() call, but not the
site of the exception.  And like I said, in the actual code where this happened there was
no stack trace at all, just the error message.  Fortunately, the message is pretty descriptive
so easy to track down.  I don’t know why my actual code generates  MissingPropertyExceptionNoStack,
but the example does not.  Anyway, it’s an obscure corner case, just thought I would point
it out.

First project using Groovy, enjoying it so far.  Thanks!
Mime
View raw message