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!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!club-internet.fr!feedme-small.clubint.net!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Inherited Methods and such Date: Wed, 26 Sep 2007 19:01:41 -0500 Organization: Jacob's private Usenet server 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: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1190851132 10998 69.95.181.76 (26 Sep 2007 23:58:52 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 26 Sep 2007 23:58:52 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Xref: g2news2.google.com comp.lang.ada:2154 Date: 2007-09-26T19:01:41-05:00 List-Id: "Maciej Sobczak" wrote in message news:1190843408.713838.128690@g4g2000hsf.googlegroups.com... ... > > 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. 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. > 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. Well, if you insist on doing bad things in your constructor (calling dispatching routines), you will obviously get problems. So what? I'm not sure what your argument is. It's surely not possible for a language to catch all possible errors (simply because not everything can be proven), so there are always going to be things that as a programmer we're going to have to avoid. That's part of the reason why programming is not something everyone can do. There is no possible mechanism in Ada that could prevent calling of dispatching routines in bad places. Changing tags cause a number of bizarre anomalies (and also would probably destroy the existing Ada implementations, all of which assume that tags never change). Additional "hooks" would help nothing, because you still could do the bad thing (calling dispatching routines inside the hook). So it seems this is a discussion of limited relevance to Ada. Following any one of a number of good Ada practices would have avoided the problem: Don't redispatch in a constructor (or Initialize) routine; don't leave scalar components/objects uninitialized at declaration; never assume a scalar object is initialized. Maybe this isn't ideal, but it is what we've got. Randy.