Re: tagged record child: override constructor?

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

On Wed, 14 Sep 2005 11:05:10 +0200, Maciej Sobczak wrote:

> Dmitry A. Kazakov wrote:
> 
>> There is no difference between T and
>> T'Class (the source of countless problems.)
> 
> Could you elaborate?

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.

2. There is no chance to get a consistent type system where each specific
type would have classes and primitive operations. If Boolean and
Boolean'Class have to be same, then the size of Boolean cannot be 1 bit.
(Presently Ada does not use this opportunity, but I hope it some day will)

3. It is inefficient, because it has to dispatch everywhere (except for
constructors and destructors, which still have the overhead of unused
dispatching.) Maybe this is the reason why so many people believe that OO
isn't suitable for real-time. I believe that this is rather an ungrounded
projection from C++ to Ada.

4. It is error-prone because of enforced re-dispatch (see below.) One
should explicitly specify T::Foo() referring member functions within a
member function. In practice nobody cares to do this, which often leads to
nasty surprises.

5. When T and T'Class are same, objects have identity. This identity might
be arbitrary. Nevertheless people will exploit it. This leads to bad
fragile design. Another form of identity is the object's address. Which is
quite similar case. Here again Ada prevents you from occasional using this
sort of identity (you have to make the object aliased), while C++
encourages it (you can apply & to almost everything.)

>> So all operations re-dispatch
> 
> What does that mean?

type Base is tagged ...;
procedure Foo (X : Base); -- Primitive operation
procedure Bar (X : Base);  -- Another primitive operation

procedure Foo (X : Base) is
begin
   Bar (X); -- This does not dispatch! It calls Base.Bar
end Foo;

The implementation of Foo stay consistent no matter what a derived type
would do with Bar. Note that this is nothing but a trivial contract model
which C++ lacks in this case. Within Foo, X is declared of the type Base.
So it would be infeasible to dispatch again. The type is known. If dispatch
is really needed, then that should be specified in the contract. I.e. the
type of X should be Base'Class. [Ada allows explicit conversions to
Base'Class, a bad idea though. Better pattern is to make the objects
explicitly having identity, using the Rosen's trick.]

Re-dispatch usually indicates a design problem.

>> except for constructors and destructors, which don't.
> 
> They do, but there the dynamic and static type of the object is the 
> same, which actually saves a lot of problems.

Yes, they do as if they wouldn't. To me it is that they don't.

Of course this saves the problems just because there is no re-dispatch,
which is in general a bad thing. Actually what C++ does in constructors and
destructors is using Ada's (consistent) model.

>> I.e. it is rather C++
>> where the call site determines whether a virtual function dispatches.
> 
> It always does, independent on the call site. It is rather the dynamic 
> type of the object that changes during construction and destruction, 
> thus leading to the "virtual functions don't work" impression.

Yes. It changes from T'Class to T and backwards depending on the location,
utterly inefficient and very error-prone.

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