Re: tagged record child: override constructor?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 14 Sep 2005 06:52:55 -0700, Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> 1. It is space inefficient. To have T and T'Class same requires keeping the
>> type tag in all Ts, while it is only necessary in T'Class.
> 
> No Ada implementation takes this approach, though.
> They all keep a type tag in every tagged object.

May be, so what? I already said that Ada 95 didn't use all advantages of
its OO model. The question was about the model, not its particular
implementation in Ada 95.

>> 3. It is inefficient, because it has to dispatch everywhere
> 
> In C++, however, you have already declared some functions to be
> dispatching (virtual) and some not.

Which is bad. All operations should be primitive if not specified
otherwise. Moreover, it would be reasonable to prohibit operations whose
arguments are neither controlling nor class-wide. The only reason not to do
this is absence of multiple dispatch.

> For those functions which are
> virtual, dispatching is what's wanted. How many Ada newbies get
> completely confused trying to figure out what dispatches and what
> doesn't? Do any of them write T'Class the first time?

Why should they care? Most of the operations are primitive, yet meaningful
dispatch is rare. How often the specific type is really unknown?

A goal of Ada design was safe software construction. Putting former C++
programmers on the right track wasn't. (:-))

>> 4. It is error-prone because of enforced re-dispatch
> 
> It is error-prone not to dispatch, because the first thing everyone
> learns about OO is that methods dispatch!

In the past everyone learnt that the Earth is flat...

The effect of C++ as the first language is sometimes comparable to
undergoing the lobotomy...

>> 5. When T and T'Class are same, objects have identity.
> 
> Huh? All type tags for a given type are identical. Why does embedding
> a type tag in an object give it any more identity than not doing so?

Because having the tag you can determine the object's type, which might
differ from what the contract states. Ada is based on contract model.

>> The implementation of Foo stay consistent no matter what a derived type
>> would do with Bar.
> 
> Except that when the programmer overrides Bar for derived types,

Especially in this case!

> he's going to be monumentally confused as to why Foo isn't calling
> it.

Because it is the contract to determine what's going on.

>> Yes, they do as if they wouldn't. To me it is that they don't.
> 
> As has been repeatedly demonstrated to you, this is just wrong.
> Once again, here is the code:
> 
>     struct A {
>         virtual void f() { print("A"); }
>         void g() { f(); }
>         A() { g(); }
>         ~A() { g(); }
>     };
>     struct B : A {
>         void f() { print("B"); }
>         B() { g(); }
>         ~B() { g(); }
>     };
>     int main() { B b; }
> 
> This will print "ABBA", demonstrating that dispatching is occuring
> within g() even when it is called from a constructor or destructor.

It demonstrates that in the calls made from T::T and T::~T the type of
"this" is T.

f() in A::g() dispatches only if g() wasn't called [directly or indirectly]
from a constructor or destructor. If that was A::A then it calls A::f(). If
that was B::B then it calls B::f() (which might be inherited from A.) And
so on.

No mystery, just a mess.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de