Re: tagged record child: override constructor?

["Hyman Rosen" <hyman.rosen@gmail.com>]

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).

> That's your view on OO, which is clearly inconsistent with the notion of
> types.

Perhaps with your notions of types.

> is "by-reference" a type property?

Yes. In C++ you have "type" and "reference to type" and the two
are completely different. 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.

> 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.
It's a separate object within its lifetime, and when the function is
called, it's initialized with a copy of the argument. 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.
(Actually, newbies in C++ face the same confusion between paramaters
of T and T& as Ada newbies do between T and T'Class.)

> 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. Trap is when the declared type does not determine what's going on.

In C++ the declared type does determine what's going on.
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.

> I (again) formulate the properties of Ada's model:

But no Ada compiler implements the model the way you would like
it to be. And I believe that allowing conversion from T to T'Class
is a requirement of Ada.

> 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. 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.

> 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.

> I don't know what "separate" members are. Do you mean memory location? Why
> should I care of?

I mean "different", or "distinct", or "not the same", or any other
synonym you care to pick.

> 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. There is only an
A::g(),
and it operates on an A object which is standalone or which is a base
subobject of an object of a class derived from A. Because B inherits
g() from A, you may also refer to it as B::g, much as Ada lets you
rename one thing as another, but it is only a different name for the
same thing. And if you have a 'B b;' it's perfectly legal to say
'b.A::g();'.

> X->B::g (); // Error, how so? X is of B, or maybe not quite?

Because the rules of C++ (3.4.5/4 of the Standard, if you would like
to check) say that the name preceding the :: is first looked up in
context. There is no B in A, so it simply fails to compile without
ever getting to consider the g() part.