Proposition for change in D regarding Inheriting overloaded methods

[Steven Schveighoffer]

"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:f9bej0$21vn$1 at digitalmars.com...
> Steven Schveighoffer wrote:
>> I still would like a real example of how this is desirable.
>
> When author A wants to extend the API of A without silently breaking 
> derived B of which author A has no knowledge of.

I meant a piece of code that will not cause compiler error.  I believe in 
the case that A adds an overload that B does not override, the compiler will 
error when author B tries to compile his code, will it not?  Is this not a 
loud error?  I'm assuming the author of B must recompile his code when A is 
updated.

I realize now that we may be arguing the same point.  I believe my original 
solution may not be feasible to imlpement, so I have fallen back on my 
alternate solution.  I'll formally state it here:

If there is a class A, which is a base class of class B, where A defines a 
method foo(args),  and B does not define foo(args), then the compiler should 
fail to compile B indicating that the user must define B.foo(args) by 
override or by alias.

>> This argument is absurd.  How is the author of A's hands tied?  If author 
>> A changes his API, author B had better take notice.
>
> The problem is, author A adds to (not changes) his API, and B starts 
> silently failing. No compile error, no runtime error.
>

I belive that my new solution would produce a compile error upon compiling 
B.

Even in my original solution, you should see no error, but if the arguments 
of the new method are not implicitly convertable to any of B's methods, then 
code which uses B would not accidentally call the new method anyways.  If 
they were implicitly convertable, the compiler would error.

>> What if author A decides to change the way he stores protected data?  How 
>> can you prevent author B from having to understand that?
>
> Author A should be able to *add* methods and fields to his API without 
> possibly causing silent breakage of derived classes. It is ok to cause 
> them to break with a compile or runtime error, but not ok to silently 
> break them.
>

Your definition of silent error is not the same as mine.  If author B does 
not care about new APIs, he could release his code without testing the new 
method, and without finding out it throws an exception.  This means B can 
compile without the author knowing that this bomb is sitting in the new 
method.  He then can release his code unknowing that it will fail when 
someone tries to call the new method on his class.  To me, it is a silent 
error to the author of B, maybe not as "evil" as code hijacking, but still 
silent.

> If author A *changes* his API, that's a different thing entirely.
>

If author A adds any methods to his class, it changes the API.  Imagine if A 
added a method with a new name that B did not have an overload for.  This is 
augmenting the class, but will not force an exception because B does not 
define an override of that method.  What if this method "breaks" the class 
as you have alluded to (but still have not given an example)?  B is now 
forced to take into account this new method.  By your argument A's hands are 
still tied even with your solution.

-Steve