Re: abstract sub programs overriding

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

On Tue, 09 Mar 2004 08:34:03 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Yes, this is because C++ OO model is inconsistent.
>
>This is literally true, if by consistent you mean "objects have the same
>type from the start of construction to the end of destruction".
>
>> Nothing may change the object type
>
>Obviously this is not a fixed law of nature,

Well, it is a philosophical question... (:-))

>but merely a choice. C++ has chosen otherwise.

>> otherwise artifacts will inevitable show this or that way.
>
>The artifacts that show up in the C++ model is that abstract methods may
>be invoked by dispatching. The artifact that is avoided by the C++ model
>is that methods are never invoked on unconstructed objects.

The problem is that to construct an object (A) /= to construct the
dispatching table of its methods (B). C++ choice is very close to: A
implies B. Obviously it is a bad choice from many points of view. One
of them is safety, as the case shows.

>It's a perfectly
>reasonable tradeoff, since detecting dispatch to abstract methods is trivially
>easy. It's the job of constructors to make an object consistent.

True, but in practice it is difficult to view object construction /
destruction as monolitic or error free. I think that probably two
stage construction is needed. The first one for type specific
construction, the second for class-wide one (at least to have
dispatching in constructors)

>Other methods
>should never have to worry that they're being called with inconsistent state.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de
--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de