[DISCUSS] trait behavior with final methods

[Paul King <pa...@asert.com.au>]

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.

Re: [DISCUSS] trait behavior with final methods

[Paul King <pa...@asert.com.au>]

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