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

John Reimer terminal.node at gmail.com
Sat Jun 24 12:22:49 PDT 2006


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

Agree... Please fix!

(yes, another "me, too" post, but I'm hoping this helps get Walter's 
attention).

-JJR



More information about the Digitalmars-d-bugs mailing list