Proposition for change in D regarding Inheriting overloaded methods

[Manfred Nowak]

Walter Bright wrote in reply to Regan Heath:

[ reciting omitted quote!
>> you're already making an assumption, you're assuming the author
>> of B does not want to expose foo(char[]) and it's the fact that
>> this assumption is wrong that has caused this entire debate.
]
>> As others have mentioned, this assumption destroys the "is-a" 
>> relationship of inheritance because "foo(char[])" is a method of
>> A but not a method of B.
> 
> We should not take rules as absolutes when they don't give us
> desirable behavior.
[...]
>> If the author really didn't want to expose "foo(char[])" then why
>> were they deriving their class from A?  It goes against the whole
>> idea of inheritance, doesn't it? 
>
> The problem is when the base class implementor wants to add some 
> functionality (or specialization) with a new overload. A's
> implementor may be a third party, and has no idea about or control
> over B. His hands shouldn't be tied.


and in reply to Steven Schveighoffer:

> The problem is, author A adds to (not changes) his API, and B
> starts silently failing.
[...]
> If author A *changes* his API, that's a different thing entirely.


Please observe that your arguments are showing kind of ambivalence.

You want
1) that inheritance gives authors "desirable behaviour".
2) that authors needn't have "ideas about or control over" derived
:  classes
3) that authors are allowed to add to their API
4) that changing an API is entirely different, where changing is
:  anything but adding


Now assume, that I am author of class C deriving from class B.

According to wish 2) I need not have "ideas about or control over" 
classes D, that derive from my class C.

According to wishes 1) and 3) the author of B as well as me can 
carelessly "add" to the respective APIs, but according to wish 4) are 
not allowed to "change" those APIs.

 
But there is no other way than to change the API of B, if there is any 
kind of conflict between the APIs of A and B. This forces me to change 
the API of my class C. This forces the author of class D ... resulting 
in a virtual infinite recurrence.


Conclusions:
1) I do not believe that in real scenarios virtual infinite recurrences
:  are considered as "desirable behaviour" according to wish 1).
2) For escaping from this vicious circle use _composition_.
3) This reestablishes the "is-a" relationship of inheritance.

-manfred