groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: [DISCUSS] trait behavior with final methods
Date Mon, 06 Aug 2018 03:48:13 GMT
I have created a PR for this:
https://github.com/apache/groovy/pull/780

On Sat, Aug 4, 2018 at 8:08 AM Paul King <paulk@asert.com.au> wrote:

> 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.
>
>

Mime
View raw message