Final defenders

["Zdeněk Troníček"]

Stephen Colebourne napsal(a):
> I've been arguing this for some time. "Defender methods" are actually
> as important, if not more important, to the future of Java if done
> properly. The arguments in favour of limited change (default methods
> only, extra keywords, special cases) seem to be driven by a fear of
> changing the meaning of interfaces.

In other words, you propose to change one of the Java corner stones
(interfaces). This is not evolution, this is revolution.
Could you elaborate on why are defender methods, in shape you are arguing
for, so important for the future?

> I want to see the change embraced and seen as a first class citizen
> (even if that means pushing back the JDK 8 timescale). Traits are what
> this is all about, and doing it properly will pay huge dividends to
> Java over the next 5 years. Not being able to have a package scoped
> method on an interface, or a protected one will just feel wrong.

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.

> My view is that we need to add the "package" keyword scope modifier (a
> good change in general), change coding standards to always include the
> the scope modifier (deprecate the use of default scopes for methods
> and variables), and only allow default methods on default interfaces,
> like abstract methods have to be on abstract classes. These changes
> provide the bedrock on which default interfaces can have a different
> set of rules to interfaces, ie. the rules of traits.

In my opinion, these proposals address problems of little importance. The
package keyword would have been a good proposal if proposed 12 years ago.
Now we are going in direction of modules.

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.

Z.
-- 
Zdenek Tronicek
FIT CTU in Prague