On 04/10/2013 07:19 PM, Ulf Zibis wrote:
Thanks David,
Am 10.04.2013 13:32, schrieb David Holmes:
Ulf,
The discussions you refer to have been happening over a number of
years. We are way past that point now.
Yes, it's a pity, that I haven't followed those discussions early
enough. Theoretically, Java 8 is not final now, but I understand, that
changing this now would be a BIG work.
The key point is that default methods do not introduce
multiple-inheritance of state, which is where the MI problems lie,
and why we would not want to add MI and use abstract classes.
Yes, that's what I meant with some restrictions on abstract classes to
be "implementable", they should be stateless, at least for the first
round. My main concern was about the complicated/ugly syntax and
priority priority rules on the default method approach.
interface + default methods are conceptually what is known as traits(*),
you can see them as interface + method with code or as abstract class
without state,
it's the same thing.
Now, if you want traits in Java, you have 3 choices: add a new kind of
type, trait,
introduce a stateless abstract class or add default methods to interface.
All these changes require to change the VM, so all of them are *big*
changes.
The lambda expert group studies each solution and adding default methods
to interface is the path that creates less problems, that why it was chosen.
Thanks for your feedback,
-Ulf
Rémi
* for Scalaist, Scala traits are not traits or at least not traits as
usually defined,
the usual definition says that a trait is stateless.
Regards,
David
On 10/04/2013 6:47 PM, Ulf Zibis wrote:
Hi all,
when I see all the extensions on interfaces via the new default
construct, I still have the feeling, such entities should be seen and
named as "normal" abstract classes. This would additionally allow
protected and private members, which otherwise can be a cumbersome
restriction.
To be compatible to legacy code, IMO it would be enough to extend the
usage of keyword "implements" for abstract classes. I'm aware, that
there should be some restrictions on such abstract classes to be
manageable as interfaces, but not as strict as for current interface
default method approach.
In fact, the interface default methods is the introduction of
multi-inheritance in Java throug the backdoor, so why not give it a
prominent full featured place and handle and name it as such?
Is there anybody willing to discuss the reasonable for the "lousy"
makeshift as I see the default method construct:
- verbose ugly syntax
- cumbersome restrictions
- unnecessary complicated priority rules:
- - some of the priority collisions could be handled by simply
distinguishing between e.g. "implements Map" and "extends Map"
From the call site view, I'm not aware, if it would make any
difference, having e.g. j.u.Map as interface or abstract class:
Map myMap = new HashMap();
myMap.doSomething();
Regards,
-Ulf
