Re: tagged record child: override constructor?

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

On 16 Sep 2005 07:52:36 -0700, Hyman Rosen wrote:

> I still think
> that Ada's requirement that tagged types be passed by reference
> shows that it was a mistake for the language to try to conceal
> the parameter passing mode from the programmer.

Why do you think so? The program semantics should be independent from the
parameter passing mode. The type identity is another thing. Though IMO, it
is always suspicious from the design point view to have objects with
identity. Fortunately Ada does not re-dispatch by default. I say
fortunately, because it was a number of times were the compiler gave me the
message, that a class-wide was expected, but a specific type was found
instead. I can remember none of them, where the program were right. In C++
these errors would slip through.

>> But the actual parameter may have another type. It leaks!
> 
> Irrelevant. When the paramater is of a specific class type
> and you pass a derived type as an argument, the parameter
> simply receives a copy of the base part of the argument.
> It's referred to as "slicing". And just as you claim to prefer,
> once that happens there is no going back to the derived type.
> The parameter is well and truly only of its declared type.

But it is not a copy of the actual object. It is a copy of its part! The
point is that T and T& are no less different C++ than T and T'Class in Ada.
But in C++ T& is overloaded with two different meanings: closure of types
(class) vs. reference type. As a consequence T& is always a reference to
class (except from con/destructors (:-)) You cannot have a reference to a
specific type. Same with pointers. In Ada both renaming (a rough equivalent
of reference) and access types can be either specific or class-wide. Wasn't
Java's final types an unsuccessful attempt to mend this? Further, because
T& is not an object, you cannot do such elementary thing as to copy a
polymorphic object.

>> "A type is characterized by a set of values..."
> 
> But what is the set of values for a tagged type?
> Doesn't it include the values of all possible derived types?

No. It is the class rooted in the type which do. A T'Class serves as a
closure of all types derived from T.

> After all, reading 4.6, it certainly seems that I'm allowed
> to do view conversions back and forth between base and derived
> tagged types.

A view conversion is still a conversion. If all types had classes, then for
non-tagged types T<->T'Class were a full conversions constructing new
objects.

In Ada there are things much close to this pattern. Unconstrained array
types are similar to classes, their constrained subtypes are similar to
specific types. Here bounds play the same role as the tag does. Note that
the language does not define how bounds are passed back and forth. It also
allows to pass arrays by copy and throw known bounds away.

>> There is a great difference between not yet implemented things and ones
>> which cannot be under any circumstances.
> 
> The requirements for view conversion and by-refernce passing
> make it seem to me that no Ada compiler will ever implement
> your version of things.

This is required for tagged types only.

Let's wait until people finally turn sick of templates! (:-))

>> The argument "this" is first converted from B* to A*, then this->A::g() is
>> called, then it is converted back to B*.
> 
> And when this->A::g() calls f(), it does so by dispatching, regardless
> of whether the A::g() call originated in a constructor or not.

Don't you see that the following two interpretations are equivalent:

1. It dispatches, but the tag changes

2. It does not dispatch, and the tag is constant.

It is clear that you prefer (1) because your mental model is many types -
one object. But I stick to (2) because I am convinced that the multiple
types model will show itself infeasible, should somebody try to formalize
it.

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