From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,436e4ce138981b82 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-03-09 06:39:09 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!tar-meneldur.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: abstract sub programs overriding Date: Tue, 09 Mar 2004 15:49:45 +0100 Message-ID: <5cmr40t76va200betf07b7bd6er05ltto9@4ax.com> References: <5f59677c.0403021101.4ac263d0@posting.google.com> <5f59677c.0403060718.3d6aa909@posting.google.com> <1078776213.376775@master.nyc.kbcfp.com> <1078839257.157439@master.nyc.kbcfp.com> NNTP-Posting-Host: tar-meneldur.cbb-automation.de (212.79.194.119) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1078843147 64365515 I 212.79.194.119 ([77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:6188 Date: 2004-03-09T15:49:45+01:00 List-Id: On Tue, 09 Mar 2004 08:34:03 -0500, Hyman Rosen 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