groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <>
Subject [DISCUSS] trait behavior with final methods
Date Fri, 03 Aug 2018 22:08:50 GMT
As per GROOVY-8722, we currently ignore, i.e. throw away, the
final modifier for any methods in a trait. We don't claim to support
it but we don't indicate in the doco that we ignore it either.

In normal Java inheritance such a method would typically be in
a base class. Java doesn't allow final default methods in interfaces.
Such a method isn't typically useful for the "api evolution" use case
that Java default methods were striving for. The way we implement
it, the method gets woven into the class but the final modifier is
dropped. We can easily fix the trait mechanics to keep that modifier.
But the question is what to do/allow in various edge cases.
In particular, should we allow a final method to be provided in
a class implementing a trait with that final method? And if so,
must it also be private. What about final methods with the
same signature from other traits?

I think there are two behaviors which make the most sense:
(1) throw a compilation error if non-final and final methods are mixed.
(2) allow the current rules exactly as they are now and whichever
method wins for inclusion in the class determines what the modifier
should be.

I am leaning towards (2) which is closest to current behavior but
keeps the modifier. Obviously we should document this.

Cheers, Paul.

View raw message