Re: tagged record child: override constructor?

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

On 15 Sep 2005 11:54:15 -0700, Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> There is no actual type, there is only the type specified by the contract.
> 
> There is an actual type, and it can be recovered from the object
> through redispatching (or even by simply extracting the type tag,
> if I'm not mistaken).

You are. Tag is said to be "associated", the standard does not require to
engrave it on the objects. Moreover, X'Tag is valid for class-wide objects
only! See 3.9 (11) 

>> is "by-reference" a type property?
> 
> Yes. In C++ you have "type" and "reference to type" and the two
> are completely different.

So T and T& are two different types, then why methods of T can be used with
T&? Is there a type conversion between them? When T is converted to T&, why
it dispatches to methods of T rather than to ones of T&? A poor C++ newbie
asks why the following does not compile:

class T& {}; // Isn't T& a type?

> A "reference to type" may have as its
> referant a sub-object of the given type which is a base class of
> a larger object. An object of "type" is exactly that. Both of
> these concepts are useful.

T != T& is useful, you say. Then why T /= T'Class is not? (:-))

>> Why by-copy objects (of which type?) have one (which?) type while
>> by-reference objects (of which type?) have more than one?
> 
> It's not the "by-copy" that gives something a type. When you declare
> that a parameter has a class type, it has that type and nothing more.

But the actual parameter may have another type. It leaks!

> It's a separate object within its lifetime, and when the function is
> called, it's initialized with a copy of the argument.

A copy, really? It is a strange copy, when the actual parameter is of a
derived type. Your theory leaks.

> When you have
> a parameter of reference type, when the function is called it's
> initialized to refer to the appropriate subobject of the argument.

Now you have a difficult job to explain what is a subobject. Which type it
has. Is it a by-reference or by-copy type, etc. Poor old C++ newbie!

> (Actually, newbies in C++ face the same confusion between paramaters
> of T and T& as Ada newbies do between T and T'Class.)

Huh, that's the minor confusion they face in C++...

>> It is rubbish. In a typed language an object has a type, only one type.
> 
> You may not like it, but that's the way it's done, including in Ada.

No, Ada is consistent here:

"A type is characterized by a set of values, and a set of primitive
operations which implement the fundamental aspects of its semantics. An
object of a given type is a run-time entity that contains (has) a value of
the type." 
   - ARM 3.2 (1)

>> No. Trap is when the declared type does not determine what's going on.
> 
> In C++ the declared type does determine what's going on.

Finally! (:-)) I.e. C++ is not a typed language. What else evidence you
need?

> In Ada, you are permitted to go from the declared type to the
> classwide type, so by your argument C++ reflects the contract
> model better than Ada does.

Allowing specific to class-wide conversion was in my view a mistake.
However, even though it contradicts to Ada's model, technically it is not a
big issue, because tagged types are by-reference anyway. When Ada will have
T'Class for non-tagged types as well, for those this conversion will not be
allowed.

>> I (again) formulate the properties of Ada's model:
> 
> But no Ada compiler implements the model the way you would like
> it to be.

There is a great difference between not yet implemented things and ones
which cannot be under any circumstances.

Alone to separate T and T'Class was a revolutionary breakthrough,
importance of which many people still do not grasp.

>> Now show me how C++ or Java could accomplish 1..12.
> 
> C++ doesn't have polymorphic variables or copying, so some things
> are out of reach. But the main problem with your approach is that
> no one wants to implement differently sized pointers for T'Class
> than for T.

Egh? Ada vendors have used fat pointers for decades. Even in C++, print
sizeof() of a member function pointer!

> For all your posting on this, I've yet to see an
> implementor so taken by your approach that he's willing to adopt it.

Come on, c.l.a. is a chat root. Do you think I have influence of Bjarne
Stroustrup, or what? (:-))

>> What should that code prove? That pointers to members is a total mess in
>> C++? Everybody knows it.
> 
> It proves that they're equal. *That's* what everyone knows.

Pointers are equal, so what?

>> They cannot be same because they act on different types. You cannot call
>> B::g() on A. The same question again, is C++ typed?
> 
> As I said, in OO languages like Ada, C++, and Java, when you have a
> reference type, the object to which it refers may be a typed base
> subobject of a larger object of different type.

See? It is of a different type. Now observe that B <: A, it is an
asymmetric relation. So B::g() cannot be same as A::g(), because that would
require equivalence B :=: A, which is wrong. This is why you cannot call
B::g() on A, even if B::g() was inherited, not overridden. My example shows
this. At least here C++ is consistent.

[my "theory" on]
The difference between A::g() and B::g() inherited from A is that B::g() is
a composition of three functions:

B::g() :=: (B *) o A::g() o (A *)

The argument "this" is first converted from B* to A*, then this->A::g() is
called, then it is converted back to B*. These conversions might be
identity ones (not always in presence of multiple inheritance, BTW), but
that gives no right to declare A::g() and B::g() same.
[my "theory" off]

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