Re: Question about OO programming in Ada

[Hyman Rosen <hyrosen@mail.com>]

Dmitry A. Kazakov wrote:
> No, the reason is that redispatch violates strong typing. If the
> contract of a subprogram is that some parameter has a specific type

But it's only in your mind that such a contract exists.
Certainly in C++, whenever you have a pointer or reference
to a class object, it is always the case that the pointed-to
object may in fact be of a more derived class. Even in Ada,
don't derived classes inherit the subprograms of their base
class unless those are overridden? Or does Ada act as if the
subprograms had been rewritten line-for-line with the new
type in place of the old one?

Not only that, but objects are often members of other objects.
Your "parameter of a specific type" may be a field of a record,
or a member of an array, or the base part of a derived object.
Redispatching is simply one way of going from the inner object
to the containing one, in much the way access discriminants are
touted here.

> This is C++ design fault which uses same notation for
> both class-wide and specific types.

The designers felt, and I think experience has borne out, that
redispatching behavior is what is wanted and expected. You can
always prevent redispatching, if that's what you want, by saying
     p->SpecificClass::function();

> Both faults stems from redispatch, which cannot be implemented in a
> type-safe and type-consistent way.

Redispatch in C++ seems perfectly consistent and type-safe to me,
since I don't make false or wishful assumptions about what a
declaration means, but rather accept the language's specification
of that. I believe the same is true for Ada.

> I don't argue against dispatch tables. My point that a dispatch table
> belongs to a subroutine, not to an object. Then OO, as an approach,
> has little to do with implementation issues. It only states that there
> are dispatching subroutines. Note, subroutines, not "dispatching
> objects".

That may be your view, but it certainly isn't the ordinary one.
Rather, there are a bunch of unrelated subprograms that happen
to share a name and parameter profile, and a system invokes one
of those subprograms when a dispatching call is made to that
name and parameter profile.

> It is exactly not the case:
> 
> class X 
> {
> public :
>    virtual void Foo () { printf ("X::Foo"); }
>    virtual void Baz () { Foo (); }
>    virtual ~X () { Baz (); }
> };
> 
> class Y : public X
> {
> public :
>    virtual void Foo () { printf ("Y::Foo"); }
> };
> 
> void main ()
> {
>    Y A;
> 
>    A.Baz (); // dispatches to Y::Foo
> 
> } // Y::~Y does not dispatch to Y::Foo
> 
> This should print:
> 
> Y::Foo
> X::Foo

Why did you not also include in Y
     virtual ~Y() { Baz(); }
Then you would see that it prints
     Y::Foo
     Y::Foo
     X::Foo
showing that Y::~Y does first dispatch to Y::Foo.
You left out the case that demonstrates that I am correct.