RFR: 8004518 & 8010122 : Default methods on Map
forax at univ-mlv.fr
Wed Apr 10 18:24:49 UTC 2013
On 04/10/2013 07:19 PM, Ulf Zibis wrote:
> Thanks David,
> Am 10.04.2013 13:32, schrieb David Holmes:
>> 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
it's the same thing.
Now, if you want traits in Java, you have 3 choices: add a new kind of
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*
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,
* for Scalaist, Scala traits are not traits or at least not traits as
the usual definition says that a trait is stateless.
>> 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
>>> 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();
More information about the core-libs-dev