***** D method override mechanisms borked ****** (some more borkiness)

[Sean Kelly]

Bruno Medeiros wrote:
>
> Also note, you said D seems to behave as C++ and Java, but Java and C++ 
> work differently. Whereas Java allow covariant overriding only, C++ 
> allows (for what I've tested) for variant overriding, that is, you can 
> change the protection either way (widening or strictening[this word 
> spelled incorrectly]).

Oops.  I wasn't aware that Java had this restriction.  Consider me 
corrected.

> Second, I just noticed something in the spec that seems inconsistent or 
> in error (I'm surprised that no one else mentioned this):
> 
> On http://www.digitalmars.com/d/attribute.html , Protection Attribute, 
> it is said: "Private members cannot be overridden."
> 
> Seems fine to me. But on http://www.digitalmars.com/d/function.html , 
> Virtual Functions, it is said: "Functions marked as final may not be 
> overridden in a derived class, unless they are also private." !

I think this statement is just poorly worded.  Private functions should 
be considered final with respect to their presence in the vtbl, but not 
with respect to whether a function of the same name may be declared in a 
subclass.  ie. they should be the same as non-virtual functions in C++.

> What this says not only seems a clear contradiction, but also broken 
> design! However, according to the following very example on that page, 
> the final private method is not overridden at all, since "a.bar()" calls 
> A.bar and not B.bar. In fact, there seems that there isn't any 
> difference from the normal(non-final) private method in the example. So 
> maybe Walter got the design right in his mind, but wrote a mistake in 
> the spec there? (it seems more natural and consistent to me that final 
> private methods are not at all different from private methods).Comments?

To me, final implies that the function may not be overridden.  But for 
overriding to take place, the function must be visible.  If a function 
is private it is not visible to child classes and therefore should not 
be considered when sorting out overrides.  ie. all private functions are 
implementation details and to child classes it should be as if they 
simply don't exist.


Sean