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,FREEMAIL_FROM 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-14 21:59:33 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!news.moat.net!border1.nntp.sjc.giganews.com!nntp.giganews.com!local1.nntp.sjc.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Sun, 14 Mar 2004 23:59:33 -0600 Date: Mon, 15 Mar 2004 00:59:32 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: abstract sub programs overriding References: <1078776213.376775@master.nyc.kbcfp.com> <1078839257.157439@master.nyc.kbcfp.com> <5cmr40t76va200betf07b7bd6er05ltto9@4ax.com> <1078845298.702789@master.nyc.kbcfp.com> <0ipr40thtf86b520a0qdi003aj87gtuhd4@4ax.com> <1078849973.701176@master.nyc.kbcfp.com> <1078924150.268074@master.nyc.kbcfp.com> <1078934469.744922@master.nyc.kbcfp.com> <1078949096.760629@master.nyc.kbcfp.com> <1079013337.572283@master.nyc.kbcfp.com> <9_mdnfzBlfEC3M_d4p2dnA@comcast.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.147.77.160 X-Trace: sv3-LYECMoRT2r1+yETJ7v09ZWkeZwf553IE6a4iWflsjQVdAEMu/jwd5QbVo/eUfUIhWuSot8cwo4ghJ7i!bGVPwGK60eu+pAbgqDNkpFLamIRSuv1Gr74s+BHZP1sE5ylbL7gEopYx1m0wBA== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:6330 Date: 2004-03-15T00:59:32-05:00 List-Id: Hyman Rosen wrote: > Why not? If Object is of a Controlled type, and this code is performing > an assignment to it, doesn't that cause Finalize to be called on the > object before the assignment takes place? If you look at what I was talking about, what would happen is that Finalize for the parent type would be called--after it had been Initialized. The Initialize for the child type won't have completed (you are still inside it), but that is not a problem since Finalize for the child type won't be called. It all gets pretty complex if you have to "follow the bouncing ball" for some reason. But in practice you never have to worry about it. Unless of course, you are a language lawyer playing games. ;-) >> So "down casting" to a child type in the body of the package which >> declares the parent is not illegal as such. > > > Note that I have never suggested downcasting to a child type. > I have just suggested view converting to the parent's classwide type, > and then calling a dispatching routine on this classwide type. Ah, if you do that there is no issue to think about. The subprogram that will be called is the same one that would have been called if you hadn't made the call classwide. All that you have insured is that the dispatching will occur dynamically. However if the Initialize for the parent type is called by the Initialize for the child type, and you do this, it is the child's subprogram that will be called. (The dispatching will look at the actual tag, not at the designated type.) And as I said, don't do that. It can be made to work, but in general it is not what you want, and the extra work at compile time (or during debugging) to resolve ABE (access before elaboration) problems just isn't worth it. In general the only time you want/need to make an explicit classwide call inside another dispatching operation is when you are doing multiple dispatching. And that is another can of worms. (I have done it. In fact, for most PL/I compilers the any-to-any default routines are written that way. The problem is completely language independent. For example, the Multics PL/I compiler had 17 different types which had to be handled by the any-to-any operators. In theory there are 4913 cases to be dealt with. In practice there were only about 150 special cases, but that was at least 100 too many.) > I certainly don't know enough about Ada's elaboration order rules to > know whether they would prevent the scenario I'm thinking of. > I accept that the whole thing is unlikely. Oh, they'll get ya. The point I keep trying to make is that only language lawyers and compiler vendors should worry about those cases. And even then they don't get paid well enough. ;-) When I am not writing compiler or ACATS tests, I never have to worry about order of elaboration. But I have also written code that sails very close to the edge. I can assure you that the frustrating thing about elaboration order problems is that they are an emergent property. The unit the compiler fails to compile, or the routine that raises Program_Error at run-time, is almost always not the one where the problem is. -- Robert I. Eachus "The only thing necessary for the triumph of evil is for good men to do nothing." --Edmund Burke