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!news2.google.com!news.glorb.com!newsfeed.straub-nv.de!noris.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Sat, 28 Feb 2009 19:39:44 +0100 From: Georg Bauhaus Reply-To: rm.tsoh+bauhaus@maps.futureapps.de User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Why constructing functions is a mess [was Language lawyer question: task activation 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> <49a97231$0$30236$9b4e6d93@newsspool1.arcor-online.net> <1mjbcbequf1wz.1o3nwuz7oqteo.dlg@40tude.net> In-Reply-To: <1mjbcbequf1wz.1o3nwuz7oqteo.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <49a984f6$0$30226$9b4e6d93@newsspool1.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 28 Feb 2009 19:39:51 CET NNTP-Posting-Host: c0b8dd96.newsspool1.arcor-online.net X-Trace: DXC=@@BAC`0JhWefF8a^:6>b7eic==]BZ:afn4Fo<]lROoRa^YC2XCjHcbi\cIhE]BZjMbA:ho7QcPOVcm>CHHjcW02fcaZ Dmitry A. Kazakov wrote: > On Sat, 28 Feb 2009 18:19:38 +0100, Georg Bauhaus wrote: > >> Dmitry A. Kazakov wrote: >> >>> 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; >>> }; >> I don't understand. Your example read >> >> type T (<>) is abstract tagged limited private; >> private >> type T ( ... constraints ...) is ... >> >> So there is no way for a client to declare an object of type T, >> for one thing because there is no way to provide constraints. >> Consequenty, a corresponding C++ class T cannot have a public >> constructor (I thought). > > You did wrong. I'm not sure I did. Why, if I can bother you on a Saturday? > T is abstract. Yes, so is class T. Also, there is no way to provide an initial value for char c that could constrain or discriminate the object. > Its discriminants is an implementation detail Maybe some discriminant is implementation detail but that is not for the client to consider. At least when type T(<>) ... expresses "Don't mess with T(<>)." type Power_Plant (<>) is abstract tagged limited private; private type Resource is (Sun, Dung, Coal, Oil, Uranium); type Power_Plant (Driven_By: Ressource) is ... To me, the public view means I should not try do do anything that isn't cared for in T's public view. I'd want to turn that discriminant into derived types, relly, but when I haven't written the package with T in it, then I can't rewrite it. Can I ask you again why you want to derive a type from a "really private" type T (<>) is abstract tagged limited private;