C++ inheritance and overloading problems

[Ravi Pandya <ravi>]

Date: Mon, 4 Dec 89 21:53:08 PST
   From: tribble (Eric Dean Tribble)

   I'm not sure shadowing is a design bug.  Imagine:

   CLASS(Derived,Base);
   Base::fun(Base * arg) {...}
   Derived::fun(Derived * arg) {...}
   ...
   {   Base * p;
       Derived * q = new Derived();

       p = Derived();
       p ->fun(q);
   }

This should clearly call Derived::fun(Derived *), since it is the
closest available match. And then "p->fun((Base *) q)" would call
Base::fun(Base *), since it would be the closest match. In any case,
the problem is independent of the relationship between the classes of
the arguments. The example I showed had foo(I,I) hiding foo(A*).

   I think this is the example I want.  Think about the type resolution
   rules required.  I'm sure I could come up with an intractable example.
   This results from the interaction between runtime dispatch and
   compile-time dispatch.  I expect they decided that subclasses can't
   redefine the types of member functions without overriding the
   inherited type.

   dean

The type resolution rules as stated in the spec should resolve this,
at least for (I,I) vs (A*). It's the same as for function overloading,
with the receiver just considered to be another argument. For the case
you give, it less clear, but I think it is still resolvable: Choose
the best match for the explicit arguments among the methods available
to the receiver's compile time type, and then dispatch according to
the run time type. (Each combination of argument types can be
considered a separate message like in our Smalltalk
"at.IntegerVar:store:" constructs.)
	--ravi