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

[Lars Ivar Igesund]

Dave wrote:

> 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

Actually, Walter has stated in the past that if Java and C++ do something
differently, he choose the C++ way. Now that almost nothing work in a way
that anyone understand, I think it might be time to start over with OOP
semantics that is best for D, no matter how it is done in C++, Java or C#.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi