RFR: 8004518 & 8010122 : Default methods on Map

[Remi Forax]

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
>>>
>>
>