Re: tagged record child: override constructor?

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

On 15 Sep 2005 06:19:40 -0700, Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> Which mistake? Again, it is solely the actual object's *type* which
>> determines dispatch.
> 
> The mistake of not calling the overridden method of the actual
> type of the object rather than of the declared type.

There is no actual type, there is only the type specified by the contract.
That's the whole point.

> In OO
> programming, by-reference objects have two types, their declared
> base type and their actual created type.

That's your view on OO, which is clearly inconsistent with the notion of
types. Try to ask yourself simple questions: is "by-reference" a type
property? Why by-copy objects (of which type?) have one (which?) type while
by-reference objects (of which type?) have more than one? It is rubbish. In
a typed language an object has a type, only one type.

> In OO programming, it is
> expected by the programmers that a call to a potentially overridden
> function using a base by-reference object will dispatch to the
> overridden function. If the language claims to support OO but then
> makes it easy to call these methods in such a way that overriding
> doesn't happen, and without warning, then the language has introduced
> a dangerous trap.

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

>> It is 100% safe, intuitive and unambiguous.
> 
> It is not intuitive at all, except to people whose intuition has
> been warped. It's just plain wrong.

You haven't presented anything to support this point, other than
assumptions about some hypothetical newbies.

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

1. The contract model

2. No space overhead

3. No run-time overhead caused by unnecessary re-dispatch

4. Pure OO (all types can have classes)

5. Compatible to multiple dispatch

6. Consistent with multi-methods

7. Compatible with class construction (dispatching from
constructors/destructors can be )

8. Compatible with assignment, abstract factory and all other cases, where
the result is dispatching.

9. Polymorphic object can be coped

10. Can return polymorphic objects on the stack

11. Can aggregate polymorphic objects in other objects

12. Covariant in all parameters

Now show me how C++ or Java could accomplish 1..12.

>> No. It calls B::g() which was inherited from A. I don't care if code of
>> B::g() and A::g() share memory or not. They are different functions because
>> their signatures are different.
> 
> No, they are the same function. If, for example, I included a static
> variable within it, calls to A::g() and B::g() would see the same
> variable. And for that matter, simply write this:
>     #include <iostream>
>     #include <ostream>
>     struct A { void g(); };
>     struct B : A { };
>     int main() { std::cout << (&A::g == &B::g) << "\n"; }
> and you'll see whether the compiler thinks they're the same or not.

What should that code prove? That pointers to members is a total mess in
C++? Everybody knows it.

>> It does not. It calls B::f() from B::g()
> 
> No. There is no B::g separate from A::g.

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

> Inherited functions are
> not copies, they are the same function.

They cannot be same because they act on different types. You cannot call
B::g() on A. The same question again, is C++ typed?

> There is no code you can
> write which will demonstrate a difference.

class A
{
public :
   void g();
};
class B : public A {};

B  *  Y = new B;
A  *  X = Y;

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

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