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

[Lars Ivar Igesund]

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!
 
-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi