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-Thread: 103376,dbcfe2b0a74da57e X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Inherited Methods and such Date: Fri, 28 Sep 2007 15:02:52 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1190239986.762473.204290@k79g2000hse.googlegroups.com> <1rw45b3rmvmcr$.1df4wst5oknbl$.dlg@40tude.net> <1190296353.624737.150940@y42g2000hsy.googlegroups.com> <11m13st1f92kf$.m8s6y8mc8ebk.dlg@40tude.net> <1190321119.206313.65290@57g2000hsv.googlegroups.com> <1190408526.100291.265040@50g2000hsm.googlegroups.com> <9ukf2wtqjs0q$.iuijmal4x56b$.dlg@40tude.net> <1190497995.498679.119190@19g2000hsx.googlegroups.com> <1mw3qju08q8uj.sgzht7ld9ydc$.dlg@40tude.net> <1190579805.451187.71140@d55g2000hsg.googlegroups.com> <1i8ksr774bjbj.vpmnx3c0i9qz.dlg@40tude.net> <1190646125.024072.310020@19g2000hsx.googlegroups.com> <1r9s9v6pcjifl.vp4ktk0unpd1.dlg@40tude.net> <1190753631.240548.101820@19g2000hsx.googlegroups.com> <1190843408.713838.128690@g4g2000hsf.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1191006174 17485 192.74.137.71 (28 Sep 2007 19:02:54 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Fri, 28 Sep 2007 19:02:54 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:t+rZRj+lvk+n5zEw4yaR/Q5Bxfo= Xref: g2news2.google.com comp.lang.ada:2196 Date: 2007-09-28T15:02:52-04:00 List-Id: Maciej Sobczak writes: > On 26 Wrz, 14:26, Robert A Duff wrote: >> And why "constructor functions" do not solve >> it? > > Constructor functions in Ada are functions that return new objects > (most useful for limited types since Ada 2005) can have parameters, > but they still don't acknowledge the "progressive" nature of the whole > process. I think they do, actually. At least, they can, if you program it that way. You can say (presuming T2 is derived from T1): function Make_T2 (...) return T2 is begin return Result : T2 := (Make_T1 (...) with ...) do ... end return; end Make_T2; Within Make_T1, the 'Tag of its result will be T1'Tag, even though that is really the parent part of the Result in T2, whose Tag is T2'Tag. And a call to this Make_T2 could be the parent part of some other extension aggregate in some other constructor function, with some other (deeper) Tag. >... This means that no matter whether we use Initialize or > constructor functions, the final type of the object is established at > the very beginning and is kept during the whole construction process. You're right about Initialize, and I agree with you (I don't much like it). But constructor functions are different. > If this process involves some activities on various levels of the type > inheritance chain, the ugly effects like the one from my example can > result, because primitive operations can be called bypassing the > intended order of component construction. > >> Are there other languages (c++, perhaps?) that have a complete solution >> to this problem? > > My claim in this lengthy and philosophical discussion is that C++ > provides a complete solution which can be shortly described like this: > the final type is not established from the very beginning, but is > progressively moving along the inheritance chain as the subsequent > constructors of base types complete their work. Thank's to this, > primitive operations never dispatch further than what can be > statically reasoned about. Well, I'd say that Ada is doing the same thing in my above example, except it's not "changing" the Tag of a single object -- instead, the result of Make_T1 has its Tag, and then Make_T2 has a different Tag. Within Make_T1, you can't dispatch to a T2 operation. > Implementation-wise, this can be done with "just" changing the tag of > the object as each base constructor completes. Right. Implementation-wise, the Tag of the result of Make_T1 is stored at the same location in memory as the Tag of the result of Make_T2. This memory location is overwritten after Make_T1 returns, during the evaluation of the extension aggregate. (Well, to be precise, it's the same location if the type is limited. For nonlimited, the implementation can choose to make them the same location, or can copy things.) - Bob