Proposition for change in D regarding Inheriting overloaded methods

[Steven Schveighoffer]

"Walter Bright" wrote
> Regan Heath wrote:
>> when the call to b.set(3) is made you insert a runtime check which looks 
>> for methods called 'set' in <actual type of object>, if none of them take 
>> a <insert types of parameters> you throw an exception.
>
> There is no runtime check or cost for it. The compiler just inserts a call 
> to a library support routine in D's vtbl[] entry for B.set(int).
>
>> Is this done at runtime instead of compile time because the parameters 
>> cannot always be determined at compile time?
>
> Yes.

Hm... I'm slightly ignorant on this issue, not being a compiler developer. 
After reading this, I'm thinking I need to change my proposition to my 
alternate solution, which is that the compiler should produce an error 
whenever the derived class does not override the base class's overloads (my 
alternate solution).  From your answer here, it appears that my assumption 
that the compiler can tell whether a given type of argument could be 
converted to a base class' argument type might be impossible to tell at 
compile time.  Or is it?  In any case, now that I think about it, it 
produces an O(n^2) run time as the compiler needs to check every argument 
type in the derived class to see if it can be implicitly converted to every 
argument type in the base class.  This might produce a very slow compiler.

I still believe generating a runtime error is no better than the current 
behavior of the compiler, actually I think it's worse.

>> In the original example (trimmed slightly):
>>
>> class A
>> {
>>    int foo(int x) { ... }
>>    int foo(long y) { ... }
>>    int foo(char[] s) { ... }
>> }
>>
>> class B : A
>> {
>>   override int foo(long x) { ... }
>> }
>>
>> void test()
>> {
>>   B b = new B();
>>   A a = b;
>>
>>   b.foo("hello");     // generates a compiler error
>>   a.foo("hello");     // calls A.foo(char[])
>> }
>>
>> 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.
>
> The language is assuming things on the conservative side, not the 
> expansive side, based on the theory that it is better to generate an error 
> for questionable (and easily correctable) constructs than to make a silent 
> (and erroneous) assumption.

The conservative side would be to say that it is an error to generate the 
class in the first place seeing as how it hasn't defined all the behavior it 
should.  The more I look at it, I think the best solution is not to assume 
anything, and force the author of the class to define it more clearly.

>
>
>> 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.
>

I still would like a real example of how this is desirable.


>> 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.

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.  What if author A decides 
to change the way he stores protected data?  How can you prevent author B 
from having to understand that?

Bottom line, if you derive a class, and the base class changes, all bets are 
off.  You may have to change your class.  I see no way to prevent this 
possibility.

Even with your exception solution, A can break code which uses instances of 
B by adding an overload.

-Steve