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: g2news2.google.com!news1.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!cyclone1.gnilink.net!gnilink.net!nx01.iad.newshosting.com!newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.arcor.de!newsspool3.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> <1wzjy9pzbft1m.1lut7nszfkzmp$.dlg@40tude.net> <49a95a12$0$31347$9b4e6d93@newsspool4.arcor-online.net> Date: Sat, 28 Feb 2009 17:22:25 +0100 Message-ID: NNTP-Posting-Date: 28 Feb 2009 17:22:27 CET NNTP-Posting-Host: 27e117ba.newsspool2.arcor-online.net X-Trace: DXC=^L8[2B]WE`gOKO]LCQ@0g`A9EHlD;3Ycb4Fo<]lROoRa^YC2XCjHcbi^3QAZeYME[hDNcfSJ;bb[eIRnRBaCd On Sat, 28 Feb 2009 16:36:43 +0100, Georg Bauhaus wrote: > Dmitry A. Kazakov wrote: > >> Exactly. This is why a user of public T must be able to construct T knowing >> nothing about the discriminants of T. > > I meant to say that the derivation should not work in the > following sense. T being (<>)ed, abstract, and limited means, > clients are supposed to not even try to create objects of this > type. It does not create T. It does S. (an inherited from T part of S is constructed as required by the designer of T. No any object of T is created. T is abstract.) >>>> 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. > > The constructor is private because T(<>) has private > constratints only. IOW, clients cannot construct > an object either of class T (C++) or of type T(<>) (Ada). This only shows that you provided a wrong C++ example. The right one, i.e. corresponding to the case I presented is class T { public: virtual void op() = 0; T (char constraint); private: char c; }; >> 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. > > When S is derived from some public T without a (<>), > I can name T in S'(T with ...) when T is just abstract. > This illustrates that (<>) prevents (meaningful) public derivation. No. A meaningful derivation is prevented by the language bug that confuses constructors with functions. These two different concepts evidently collide when types are abstract. You misinterpret the purpose of <>. If Ada designers wished to prevent derivation from T(<>), they would simply do it. If they did, they would also prohibit such *final* types from being abstract. Obviously. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de