Final defenders

["Zdeněk Troníček"]

Please, do not try to make Java perfect language by adding features "that
might be useful" or "that appeared to be useful in other languages" unless
you provide strong motivation examples. Otherwise you dig its grave.

Z.
-- 
Zdenek Tronicek
FIT CTU in Prague


Bob Lee napsal(a):
> I'd strongly prefer enabling private instance methods from the get-go. If
> we don't, users will make methods public that shouldn't be. If we allow
> private static methods only, I'll have to pass "this" in explicitly, and
> my
> code will look like Python.
>
> Bob
>
> On Tue, Aug 7, 2012 at 8:18 AM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
>> Just to head off the obvious follow-on questions:
>>  - What about private methods in interfaces: entirely feasible, but not
>> targeted at 8
>>  - What about protected methods: possibly trickier than private methods,
>> not targeted at 8
>>  - What about package-private methods: feasible, would require
>> additional
>> syntax (e.g., "package" modifier)
>>  - What about static methods: being considered by the EG
>>
>> On Aug 7, 2012, at 7:34 AM, Aleksey Shipilev wrote:
>>
>> > Hi,
>> >
>> > TRAITS! Now, while Brian is gasping with exertion, I'll continue.
>> While
>> > studying the it2-bootstrap branch code, I have come across using
>> > defenders in trait-like fashion:
>> >
>> > public interface StatefulOp<T, U, V> {
>> >    public boolean isStateful() default {
>> >        return true;
>> >    }
>> > }
>> >
>> > In this case, the defender is not particularly the fallback default,
>> but
>> > really an enforced implementation. However, lacking language support
>> for
>> > these cases, I can do:
>> >
>> > public class MyRogueOp implements StatefulOp {
>> >    public boolean isStateful() {
>> >        return false; // eat that!
>> >    }
>> > }
>> >
>> > ...and the defender rules will count my concrete implementation as
>> > legitimate one. This makes relying on isStateful() quite a bad idea in
>> > the library.
>> >
>> > That makes me thinking if we need to embrace it, and realize that some
>> > of the defenders are really final. My suggestion is simple: let's mark
>> > the final defenders "final"!
>> >
>> > In simplest form:
>> >
>> > public interface StatefulOp<T, U, V> {
>> >    public final boolean isStateful() default {
>> >        return true;
>> >    }
>> > }
>> >
>> > "final" is not allowed in interfaces by the current rules, so we can
>> use
>> > this loophole to introduce a new meaning. However, this feels wrong to
>> > provide the default implementation, and instantly forbid the
>> extension.
>> > So, maybe this is better:
>> >
>> > public interface StatefulOp<T, U, V> {
>> >    public boolean isStateful() final {
>> >        return true;
>> >    }
>> > }
>> >
>> > This should be more complicated to implement in compiler, but it
>> clearly
>> > mandates the method body is the final implementation.
>> >
>> > This is not completely enforceable in the compile time, and so it
>> > complicates the method dispatch a bit. We need to check if there is
>> any
>> > superclass final defender in the hierarchy, that can piggyback on the
>> > defender selection we have now. Also, two colliding defenders, no
>> matter
>> > if the pairs are default/final, default/default, or final/final should
>> > render the same error as default/default collision now.
>> >
>> > Additional concern is the evolution. We need to explore two things:
>> > 1. Can we add "final" to the defender on the existing interface?
>> > 2. Can we remove "final" from the defender on the existing interface?
>> >
>> > The answer to both seems to be "yes", because the same class of bugs
>> we
>> > have already with abstract classes and visibility rules, also
>> > unenforceable with separate compilation. We can still do compile-time
>> > checks so that code compiled at once would never throw a linkage
>> error.
>> >
>> > Thoughts?
>> >
>> > -Aleksey.
>> >
>>
>>
>>
>
>