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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM 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,UTF8 Received: by 10.66.77.1 with SMTP id o1mr1563107paw.29.1343318865590; Thu, 26 Jul 2012 09:07:45 -0700 (PDT) Received: by 10.68.223.73 with SMTP id qs9mr391412pbc.7.1343313812555; Thu, 26 Jul 2012 07:43:32 -0700 (PDT) Path: b9ni65285795pbl.0!nntp.google.com!4no1464805pbo.1!news-out.google.com!p10ni64818913pbh.1!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!novia!volia.net!news2.volia.net!feed-A.news.volia.net!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.straub-nv.de!news.swapon.de!news.glorb.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Ada 2005 puzzle Date: Sat, 21 Jul 2012 15:46:47 -0700 (PDT) Organization: http://groups.google.com Message-ID: <2a1f6145-2aa1-4af3-aca0-2fc0b3a78efe@googlegroups.com> 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> <12fbl1qrjckwi$.xk9v9nzzcj21.dlg@40tude.net> NNTP-Posting-Host: 46.171.80.166 Mime-Version: 1.0 X-Trace: posting.google.com 1342911670 26765 127.0.0.1 (21 Jul 2012 23:01:10 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 21 Jul 2012 23:01:10 +0000 (UTC) Cc: mailbox@dmitry-kazakov.de In-Reply-To: <12fbl1qrjckwi$.xk9v9nzzcj21.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=46.171.80.166; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Date: 2012-07-21T15:46:47-07:00 List-Id: W dniu pi=C4=85tek, 20 lipca 2012 14:49:14 UTC+2 u=C5=BCytkownik Dmitry A. = Kazakov napisa=C5=82: > we =3D you and me? Unfortunately, yes (although we want it for slightly different reasons, I g= uess). [...] > I meant here a different thing. If you have some dispatching operations t= o=20 > be performed upon initialization, I'm not sure what possible use-case would motivate it - I don't see any in = the container's interface. Containers are not supposed to be more smart tha= n necessary, they just have to keep objects. > Let you have a hierarchy of types T1:>T2:>T3. Then construction sh= ould run=20 > as follows: >=20 > stage 1 > T1 constraints evaluation > T2 constraints > T3 constraints >=20 > allocation >=20 > stage 2 > T1 initialization > T2 initialization > T3 initialization >=20 > stage 3 > T1'Class initialization, only here we could dispatch on T1'Class > T2'Class initialization > T3'Class initialization >=20 > >> 1-3 cannot be effectively fused into single operation Stage 3 is implicit, so we don't have to care, but I see the problem with 1= and 2. > The technical reason IMO is that steps 1,2,3 are intermixed. This prevent= s=20 > encapsulation of T1/1 + T1/2 + T1/3 into single subprogram. Right - we would have to allow non-contiguous objects (multiple allocations= for each component) and that would break the object model in almost all po= ssible places. --=20 Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com