***** D method override mechanisms borked ******

[kris]

Bruno Medeiros wrote:
> kris wrote:
> 
>> Lars Ivar Igesund wrote:
>>
>>> kris wrote:
>>>
>>>
>>>> Used to be that overriding methods in subclasses had some logic to it.
>>>> Now? Well, who knows:
>>>>
>>>> 1) you can override a protected method and make it public. Doh!
> 
> But #1 is not a bug or incorrect, see below.
> 
>>
>> The original behaviour limited the exposure of an overridden method to 
>> be less than or equal to the exposure of the original. For example, 
>> protected could not be made public via an override. The compiler would 
>> give you an error if you attempted to do so. The compiler used to 
>> prevent you from intercepting a superclass method where the original 
>> intent (of the designer) was that said method whould be internal usage 
>> only. For example, final, package, or private methods.
>>
> 
> If that was the original behavior, that behavior was broken. You see, 
> when overriding a method, limiting the protection level is unsafe, 
> whereas widening the protection level is safe. The protection level is a 
> call-site contract (like the return type) and as such is only safe when 
> overridden invariantly or *covariantly*.
> 

LOL ... you might choose to state "in the research-paper entitled zzzz 
it is noted that ....", or maybe even "language X does it this way". But 
alas, no.

I find it unfortunate that when reporting issues, it often gets turned 
into a "lovefest" over one particular point whilst vaguely dispatching 
those which clearly indicating things are broken. Almost as though 
debunking any part of a report is viewed as a grand opportunity to 
satiate some individual ego. Given that the apparent changes were never 
opened up for discussion in the first place, I suspect it would be 
foolish to partake in an open debate at this point -- concerning various 
aspects of one philosophy over another.

So let's stay on track here: what we have is a collection of buggy 
behaviour plus conflicting/confusing implementation rules. The 
end-result is something pretty much guaranteed to turn people away from 
D -- heck, I'm one of D strongest proponents, and continuing issues like 
this are driving me away. This simply needs fixing, and it needs to 
operate in an obvious, consistent, and dependable manner. Period.


 > If you designed your classes around that original behavior, they're 
broken.

Indeed they are. They were designed in strict accordance to the written 
D spec. Sean notes that certain original parts of the spec have now 
somehow silently disappeared ... no mention of such fundamental change 
was ever apparently announced or discussed.