Final defenders

["Zdeněk Troníček"]

Stephen Colebourne napsal(a):
>> Could you give any examples of those "huge dividends"? Could you show
>> when
>> protected methods in interfaces are useful?
>> I have already asked for examples of protected interface methods in this
>> conference and did not get any.
>
> JSR-310 has an example, where we have to use a "do" naming prefix
> together with lots of Javadoc for methods that should be protected on
> an interface:
> https://github.com/ThreeTen/threeten/blob/master/src/main/java/javax/time/calendrical/DateTimeField.java#L131
>
> If you look further up that same class you'll see the compare method
> is marked as one that should be a default method.

Not a good example. DateTimeField.doGet cannot be protected because it is
accessed from another package (e.g. from javax.time.AmPm).
Concerning the compare method, none of the three implementation accesses
any instance attribute and presumably should be somewhere else (low
cohesion).
If the compare method is default method in Java 8, it probably will be an
implementation of the template-method design pattern. Although such use
may be useful sometimes, it is not a big deal.

> This is an interface because it is implemented by enums. So, proper
> traits functionality would solve much of another requested feature -
> "abstract enums".
>
> By not adding protected/private/package methods from the start of this
> feature, we are going to end up with design mess-ups like the "do"
> naming prefix in JSR-310, simply to get around an inadequate feature.
>
> A second case is where I want an interface that is limited in scope to
> a package. While the interface can be declared package-scoped, all the
> methods are still public in scope. This causes the implementations to
> have to declare their methods public, which nullifies the usefulness
> of the design.

Package-scoped interfaces sound weird to me. You probably view the
interfaces as a means for multiple inheritance. As somebody noted here,
another view (mine) is that they describe the contract. (Syntactically,
not semantically).

>> Each programming language is based on some principals. Any change of
>> these
>> principals probably means discontinuity and even if the changes are done
>> in backward compatible way, they probably break the language integrity.
>> I remember the times when Java students asked "why Java does not allow
>> to
>> overload operators?". "It is so useful in C++!".
>> (Or more funny: "How do you multiply matrices in Java if you cannot
>> overload the operator *?")
>> Some features seem to be useful at the first sight but their real value
>> is
>> questionable. And I am quite convinced that if we were in 1999, some
>> people would argue for operator overloading which is useful only when
>> you
>> want to make the code less readable.
>
> Java does not override == to ,equals() or < to compareTo(). These
> changes would dramatically enhance the readability of code, and its
> noticable that the vast majority of lambda examples at conferences use
> primitives to avoid the problem of Java's verbosity within lambdas.

Overloading of operators does not improve readability, it only decreases
verbosity. Lesser verbosity does not necessarily mean better readability.

Z.
-- 
Zdenek Tronicek
FIT CTU in Prague