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-Thread: a07f3367d7,735c710b5e547bad X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Received: by 10.224.138.146 with SMTP id a18mr1380174qau.6.1343314701093; Thu, 26 Jul 2012 07:58:21 -0700 (PDT) Received: by 10.66.76.99 with SMTP id j3mr323443paw.45.1343314575675; Thu, 26 Jul 2012 07:56:15 -0700 (PDT) Path: a15ni113198934qag.0!nntp.google.com!q21no2827181qas.0!news-out.google.com!b9ni61875574pbl.0!nntp.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newspeer1.nac.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!xlned.com!feeder5.xlned.com!feed.xsnews.nl!border-1.ams.xsnews.nl!newsfeed.straub-nv.de!news.nobody.at!weretis.net!feeder4.news.weretis.net!news.mixmin.net!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada 2005 puzzle Date: Fri, 20 Jul 2012 14:49:14 +0200 Organization: cbb software GmbH Message-ID: <12fbl1qrjckwi$.xk9v9nzzcj21.dlg@40tude.net> References: <1arp60wtxes8h$.1qs6bt732ztgp.dlg@40tude.net> <030cde76-7435-405d-9f12-ac7f730ecab8@googlegroups.com> <1f9q6vk5z2r3t$.1hayo9rmxfwu7$.dlg@40tude.net> <7308644e-bfbe-44c1-8359-d67392d483e1@googlegroups.com> <72bc2c23-4a1c-4c09-985e-8cc4c0fd957f@googlegroups.com> <1uli63mb1e82x.11cuz41guddr5.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: 9A8bJrx4NhDLcSmbrb6AdA.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 X-Received-Bytes: 5119 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Date: 2012-07-20T14:49:14+02:00 List-Id: On Fri, 20 Jul 2012 04:30:27 -0700 (PDT), in comp.lang.ada you wrote: > W dniu pi�tek, 20 lipca 2012 10:27:15 UTC+2 u�ytkownik Dmitry A. Kazakov napisa�: > >> The problem is that a *new* limited object cannot be result of a function, >> this is conceptually broken. > > Yes, we have already concluded long time ago that one of the priorities > for Ada is to fix the concept of object construction. we = you and me? I bet 99% of c.l.a still firmly believe that functions returning limited objects were all OK. > But in this case I think that Ada has everything that is needed. On paper. But practically (because the concept is bogus) I suspect that there is no way to make it working in real-life scenarios. I cannot count number of cases when I was forced to redesign because of the damn problem. If Randy himself, who is a compiler designer and language lawyer, gave up, what would you expect from laymen? >> The factory of limited objects passed to >> Insert must provide means to: >> >> 1. determine the constraints of the object (using some set of arguments); > > This is not the container's business and will usually come with the > factory itself - or from the context of the factory. That is why I expect > this to be used with access to *local* functions, which can drag along all > the information that is needed to construct the object. Yes, this one of possible forms of factory. >> 2. construct the object in place (using the arguments again); > > Same as above - the constructor function can bring the "arguments" from > its surrounding context. You can even create wrappers like this: > > procedure Insert_From_Arguments > (C : in out Container; > X : in Integer; Y : in Integer; Z : in Integer) is > > function Construct return T is > begin > return V : T do > V.X := X; -- constructing T from arguments X, Y, Z > -- ... > end return; > end Construct; > begin > C.Insert (Construct'Access); > end Insert_From_Arguments; > > Above, the arguments are passed as part of the Construct's environment. > >> 3. optionally, construct the class-wide object upon the specific object >> (using the arguments) > > I expect that class-wide is what the container sees (for example, by being > instantiated with such a type) - the rest happens the usual way, by > initializing the class-wide placeholder with specific constructed object. > This way you could naturally have a container of OO objects. I meant here a different thing. If you have some dispatching operations to be performed upon initialization, these must be called on the class-wide instances, when all ancestors are already initialized. Let you have a hierarchy of types T1:>T2:>T3. Then construction should run as follows: stage 1 T1 constraints evaluation T2 constraints T3 constraints allocation stage 2 T1 initialization T2 initialization T3 initialization stage 3 T1'Class initialization, only here we could dispatch on T1'Class T2'Class initialization T3'Class initialization >> 1-3 cannot be effectively fused into single operation > > Why? What's wrong (ie. what is ineffective) with the above? ARG tried and failed. The technical reason IMO is that steps 1,2,3 are intermixed. This prevents encapsulation of T1/1 + T1/2 + T1/3 into single subprogram. Furthermore at the stage 1 there is no any object allocated. It cannot be an argument. Stage 2 needs a type-specific argument. Stage 3 needs a class-wide argument. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de