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

[Jari-Matti Mäkelä]

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.

-- 
Jari-Matti