> On 2015-12-27, at 11:51 , Jochen Theodorou <[email protected]> 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!

Reply via email to