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

[Dave]

Jari-Matti Mäkelä wrote:
> Sean Kelly wrote:
>> Jari-Matti Mäkelä wrote:
>>> 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 :)
>> I think a careful programmer could make it work through extensive use of
>> 'final'.  However, it's obviously preferable to simply fix the bug :-)
> 
> True, a careful programmer doesn't need these protection mechanics at
> all. In fact we could write some l33t stuff in pure asm as well! But
> that's not my point. I really cannot believe there's only one bug
> preventing us from having a working compiler.
> 
> There's not only some base classes and derived classes. They can also be
> nested in multiple levels and then there's modules & packages that need
> a consistent protection mechanics system with all classes. (then there's
> also templates and other possible stuff implementing protection) I don't
> get it - those all should be pretty consistent on a very high level. Now
> it seems like DMD has pretty ugly ad-hoc solutions for different situations.
> 
> Then, to me it also seems to be totally braindead to mix both covariance
> and contravariance in inheritance semantics. Overriding in Java uses
> covariance (and that's the way it should work in D too, I think). Okay.
> Then there's public/protected/etc. inheritance from C++. Not only does
> it break possible elegant uses of interfaces a la Java, but it's also
> badly documented and implemented. In fact last time I checked it wasn't
> implemented at all. If it will be implemented some day, should we expect
> some kind of runtime exceptions when using these privately inherited
> classes covariantly? That works fine in C++ because C++ does not have
> interfaces, but IMO here it only adds confusion. Well, it might just be
> that I don't "get" it yet.
> 
> Another problem related to these mechanics is that DMD is not able to
> handle the whole module hierarchy when judging the visibility /
> protection rules. A simple diamond shaped import hierarchy breaks the
> system. I wonder how it works with diamond shaped inner class hierarchies.
> 

I think this can all be boiled down to 2 things:

- Since D has chosen its OOP semantics to be based on those of Java, it 
should follow that model consistently w.r.t. co/contra-variance (after 
all it's seen pretty wide-spread use).

- Even more importantly, make the darn protection attributes consistent 
between structs, classes, modules and packages no matter if parts of 
which are implemented with templates or not!

- Dave