Re: Merits of re-dispatching

[dmitry@elros.cbb-automation.de (Dmitry A. Kazakov)]

On Fri, 22 Feb 2002 11:59:46 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> That's the whole point. Dispatching vs. not dispatching is not an
>> implementation detail, but a part of the contract. It seems that we
>> are using different definitions of dispatch, thus we'll never agree.
>
>Yes, it's part of the contract, and in C++ it always dispatches.
>There is only one definition of dispatch that I'm aware of - when
>a virtual method is called through a pointer to an object, the method
>actually called is determined by the actual type of the object, not
>the declared type of the pointer.

Compare: the actual type is class wide [no matter pointers, reference,
value], the parameter is dispatching.

>In C++, it is this actual type which
>changes as control progresses through the hierarchy of constructors
>or destructors.
>
>> No. I said exactly the opposite:
>> "The behaviour of B::~B is safe."
>
>Here is what you said in your original message:
>	C++ and Ada 95 support re-dispatching,
>	which I think is inherently unsafe

Yes this is may point that re-dispatching is unsafe. Also my point is
that destructors in C++ are safe because [in your terminology] they
dispatche as if the actual type were the formal type. This behaviour
is safe, because [according to my terminology] they do not dispatch at
all. Which IMO should be always so in a specific subroutine
[destructors cannot be class wide].

>> I definitely do not want that self-contradictory mixture
> > of types and their closures as in C++.
>
>I don't even know what this means. C++ does not have
>"self-contradictory" types.

This means, I quote you :

"... actual type which changes as control progresses through the
hierarchy of constructors or destructors."

If there is no distinction between specific and class wide types, then
somersaults like morphing types are inevitable. One cannot mix sets
and its elements without a punishment.

Regards,
Dmitry Kazakov