something "weird" about polymorphism

[Chris Nicholson-Sauls]

funog wrote:
> downs wrote:
>> funog wrote:
>>> The following code :
>>>
>>> ------------------
>>> import std.stdio;
>>> class A {
>>>     void foo(A a) {
>>>         writefln("A");
>>>     }
>>> }
>>>
>>> class B : A {
>>>     void foo(B b) {
>>>         writefln("B");
>>>     }
>>> }
>>>
>>> void main() {
>>>     B b = new B;
>>>     A a = b;
>>>     assert(a is b);
>>>     b.foo(b);
>>>     a.foo(b);
>>> }
>>> --------------
>>> outputs:
>>> B
>>> A
>>>
>>>
>>> This is understandable as B.foo doesn't actually overrides A.foo. But
>>> somehow it's weird to get different outputs while "a" and "b" are
>>> basically the same object. Has anyone else encountered this problem in
>>> real life? Will C+++, java act the same way?
>>>
>>
>> The behavior here is entirely correct and, in fact, could not happen 
>> any other way.
>>
>> The only improvement would be disallowing declaring methods that 
>> shadow but don't override methods in the super class.
>>
> 
> 
> This is the point, I think it should be disallowed (particularly in D, 
> since shadowing declarations are deprecated). I understand that B.foo 
> doesn't override A.foo, but I mean, you have the same object, the same 
> function (name), the same parameter... and a different result.
> Well, I'm not a pro so I don't know how error-prone it can be in "real 
> life".
> 

Same object, same method, same parameter... but different interface and potentially 
different invariant on that interface.  Sometimes this is a Good Thing, sometimes its a 
Bad Thing.  When it is a Bad Thing, you can generally accomplish what you want with 
"final" -- but certainly not always!

Might be another tick on the "advantages" side of using non-virtual interfaces.

-- Chris Nicholson-Sauls