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: 103376,90108ed846e3f1bf X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news2.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!cyclone1.gnilink.net!gnilink.net!nx02.iad.newshosting.com!newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.ision.net!newsfeed2.easynews.net!ision!news.belwue.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Why constructing functions is a mess [was Language lawyer question: task activation Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1dusr7frk73m7.nlsagplge0hk.dlg@40tude.net> <09a7aab3-d105-4a40-b25b-e2824cb12f89@j1g2000yqi.googlegroups.com> <24bdd0df-9554-49de-9c5e-99572c9cdf34@g38g2000yqd.googlegroups.com> <1v0f2pkso7p50.vein84avao5t.dlg@40tude.net> <499ede41$0$32665$9b4e6d93@newsspool2.arcor-online.net> <1lhxmo6l2ypux.bei2ffp1m3e$.dlg@40tude.net> <499f2c59$0$31868$9b4e6d93@newsspool3.arcor-online.net> <1vcaimc8kjj30$.kf3rsd670ebp$.dlg@40tude.net> <1gxn72yzshp07$.6ytqydmmz37u.dlg@40tude.net> <49a92c29$0$32670$9b4e6d93@newsspool2.arcor-online.net> Date: Sat, 28 Feb 2009 14:45:29 +0100 Message-ID: <1wzjy9pzbft1m.1lut7nszfkzmp$.dlg@40tude.net> NNTP-Posting-Date: 28 Feb 2009 14:45:32 CET NNTP-Posting-Host: 77032a95.newsspool3.arcor-online.net X-Trace: DXC=V[CGXP9_T4=L2C_`koXfC5McF=Q^Z^V384Fo<]lROoR1^YC2XCjHcb9@LK^@R?DQ>6eUhW?9l7K_Yf[P@e? X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:3849 Date: 2009-02-28T14:45:32+01:00 List-Id: On Sat, 28 Feb 2009 13:20:51 +0100, Georg Bauhaus wrote: > Dmitry A. Kazakov wrote: > >> Topic: large system design, information hiding: >> >> type T (<>) is abstract tagged limited private; >> private >> type T (...constraints...) is abstract tagged limited record >> ... >> end record; >> >> In order to be used in >> >> type S is new T with ...; >> function Create (....) return S; > > How/Why should this derivation be possible? Because it is so in Ada (the discriminants are inherited). The idea of <> introduced in Ada 95 was to be able to hide the discriminants. The idea of Pickwickian function was in part to overcome Ada design bug that the discriminants can be hidden but not abstracted. Note that if T weren't abstract, a Pickwickian function would work: type T (<>) is tagged limited private; function Create (...parameters...) return T; private type T (...constraints...) is tagged limited record .. Observe, that this abstracts the discriminants of T, which in the public part are represented by the arguments of Create. Now the arguments of Create are kind of "public discriminants." The private discriminants are of nobody's interest. Another Pickwickian construct is limited aggregate in which you can use a Pickwickian call to the Pickwickian function Create and this incredible combination gives us an ability to implement Create of S with whatever parameters you need. Nevertheless it miserably fails: 1. It does not work with abstract types. 2. It exposes Create of T as a primitive operation of. That means that S have to provide Create with *exactly* same arguments as ones of T! This is a catastrophe. There is absolutely no reason for S to implement this Create. It would have its own with parameters of its own. (Constructors are NOT inherited) 3. You still cannot publicly extend T if you have to add some new discriminants. Discriminants still are not properly abstracted. (This cannot be saved, it is just wrong.) >> In order to be used in >> >> type S is new T with ...; >> function Create (....) return S; > (Deriving publicly > from an abstract limited type with unknown discriminants--to me, > the <> signals the intent of the author of T, namely that T > should be considered none of our business?) Exactly. This is why a user of public T must be able to construct T knowing nothing about the discriminants of T. >> Remember? Constructor is not function. It never will. See the problem? > > Assuming C++ has constructors, will your arguments apply > in the following examples (just trying to understand): > > class T > { > public: > virtual void op() = 0; > private: > T(char constraint) : c(constraint) {} > char c; > }; No, the constructor in the example must be public. Probably you refer to the trick when <> is used to prevent uninitialized objects. But T is already abstract. You cannot create it in any way. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de