RFR: 8004518 & 8010122 : Default methods on Map

[Ulf Zibis]

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.

Thanks for your feedback,

-Ulf


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