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

[Bruno Medeiros]

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!
>>>
>>> 2) you can override a public method and make it private ... ok, but get
>>> this -- the overload is not virtual -- it doesn't "actually" overload at
>>> all. Very sneaky bug in the making, especially when the base class is
>>> altered just slightly.
>>>
>>> 3) to fix #2 let's use the override keyword! Yay! That will ensure we're
>>> actually overriding the base class method instance! Well, it compiles,
>>> but does *not* override. Bork Bork Bork.
>>>
>>> And so on, ad infinitum.
>>>
>>> This was not a problem at some distant point in the past. Now the rules
>>> are (a) too murky for this simple dude to even comprehend and (b)
>>> apparently thoroughly broken. The behaviour turns D into a land-mine for
>>> both the unwary and for the seasoned professional. How to turn people
>>> away from D in one easy lesson.
>>>
>>> Please, please, please revert whatever cleverness was injected there and
>>> make it work in a clear, precise, /obvious/, and above all, *dependable*
>>> manner. Heck, make the "override" keyword mandatory if you need to. The
>>> latter should at least work, or cause a compie-time error.
>>
>>
>> I couldn't agree more, and make sure the rules are thouroughly 
>> documented!
>>  
> 

> I seriously hope this is all just a mistake/bug/whatever, which will be 
> fixed quickly and appropriately. However ...

#2 and #3 are clearly a bug, both because override must *always* 
override, and because " Private members cannot be overridden" 
(http://www.digitalmars.com/d/attribute.html).

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

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


> Now, you can intercept all you like. The compiler does not give an error 
> at all. The following example illustrates a litany of places where the 
> compiler should halt. Just ask yourself how one is supposed to design 
> superclass functionality that should not be exposed, overridden or 
> otherwise subverted by a subclass?
> 
> 
> extern(C) int printf (char*, ...);
 > ...

As per what I said above, some of those examples are not incorrect. The 
others are.


 > Before Bruno gives me a ticket for terminology abuse, I should note that
 > the use of "overload" in #2 was completely unintentional. One should at
 > least wake up properly before getting one's daily dose of D frustration.
 >

No problem if it was unintentional. ;)

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D