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

[Jari-Matti Mäkelä]

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!

Yeah, as Bruno previously said, that should be allowed.

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

Damn, now all visibility / accessibility rules in D are totally broken.

I really don't think the system is ever going to work the way it is
documented now. The interface stuff and part of classes use the covariance
rule in inheritance. It's also possible to contravariantly inherit a base
class using class foo: private bar {} (a la C++). Then there are private
attributes in classes and modules that don't work so well either. Hmmpf,
hope someone has time to sort this out. We're counting on you, Walter :)