[DISCUSS] trait behavior with final methods

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] trait behavior with final methods

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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] trait behavior with final methods

paulk_asert
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 <[hidden email]> 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.