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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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-13 02:05:08 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!dialin-145-254-040-099.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: abstract sub programs overriding Date: Sat, 13 Mar 2004 11:12:49 +0100 Organization: At home Message-ID: References: <1078849973.701176@master.nyc.kbcfp.com> <1078924150.268074@master.nyc.kbcfp.com> <1079014276.527406@master.nyc.kbcfp.com> <67u0505uu3gfmlt8p28e9jkaco0nljquut@4ax.com> <1079019616.621636@master.nyc.kbcfp.com> <1079026002.840030@master.nyc.kbcfp.com> <1079097006.572713@master.nyc.kbcfp.com> <1079103394.507060@master.nyc.kbcfp.com> <1079116458.119831@master.nyc.kbcfp.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-040-099.arcor-ip.net (145.254.40.99) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.uni-berlin.de 1079172307 69058320 I 145.254.40.99 ([77047]) User-Agent: KNode/0.7.2 Xref: archiver1.google.com comp.lang.ada:6302 Date: 2004-03-13T11:12:49+01:00 List-Id: Hyman Rosen wrote: > Dmitry A. Kazakov wrote: >> No it is how Ada does it. Here is an example: > > WHere does your example involve constructing a T vs. constructing a > T'Class? Come on, that was a theory explaining and predicting the phenomenon = "how it works in Ada" and "why it cannot in C++". To prevent silly accusations, I don't claim that Ada designers followed that theory, I only say that Ada design is conform with the theory. >> Initializing of an object of B will print: >> Init field of B >> Init A >> showing that Initialize for A is called *after* initialization of Field >> of B. It means that A's Initialize may safely use any field of B. > > But it also means that initializing a field of B cannot safely use A! Right, because normally a *component* of B shall not know A. It is a component of B, not of A (sic!). At most it may know B or B'Class and so through these, A. This would mean a circular type dependecy recommended to avoid in any software design tutorial. If you have such dependency (for whatever reason (*), then you cannot complete initialization of the component in its constructor. BTW, you have switched from inheritance (B is derived from A) to aggreagation (In_B is a component of B). [I used In_B only to print a message showing that controlled types are constructed in two phases.] A design where one type uses another, being a field of its derivant is an awful mixture of aggregation and inheritance in one flagon. It is an instance of the aliasing problem, which is in general unsolvable, as we all know. ---------- * Typical example is a task component that refers the enclosing object through a discriminant. Here the multiple-stage initialization shows its power. The task is activated after all calls to Initialize, so the following is safe! type A; task type Runner (This : access A'Class); type A is new Ada.Finalization.Limited_Controlled with record Do_It : Runner (A'Unchecked_Access); end record; procedure Initialize (Object : in out A); -- called before Object.Do_It starts [Yet, I'd prefer MI and tagged task types, but that's another story] -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de