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!news3.google.com!feeder.news-service.com!news2.euro.net!newsfeed.freenet.de!bolzen.all.de!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool2.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: <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> <49a984f6$0$30226$9b4e6d93@newsspool1.arcor-online.net> Date: Sat, 28 Feb 2009 21:17:11 +0100 Message-ID: NNTP-Posting-Date: 28 Feb 2009 21:17:15 CET NNTP-Posting-Host: dc62ca0e.newsspool1.arcor-online.net X-Trace: DXC=H5GkYYYNk]jFXUDVUnEXQmic==]BZ:afn4Fo<]lROoRa^YC2XCjHcbiCfe5QI_]=OiDNcfSJ;bb[eIRnRBaCd On Sat, 28 Feb 2009 19:39:44 +0100, Georg Bauhaus wrote: > 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? Because the case as I put it reads: the parent type is abstract and limited, its discriminants are private. >> 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. Wrong. C++ constructor can set c as necessary. Private constraints of an object (rather their equivalents, since C++ does not have unconstrained types), are to be determined by the constructor. This is absolutely no problem in C++. >> 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(<>)." I don't get it, sorry. Please do not try to switch the discussion topic to interpretations of implied intentions beyond language constructs. > 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; Ada standard does not define "really private types." A type may have public and private views. That has nothing to do with inheritance. If you are asking why certain things were moved to private parts of a package, then it is the information hiding principle. Ada was designed in order to support it. The presented example uses (<>) because the language requires it when the discriminants appear in the private part. For the power plant example consider: type Power_Plant (<>) is tagged limited private; function Create (Name : String) return Power_Plant; function Get_Name (Plant : Power_Plant) return String; private type Power_Plant (Name_Length : Natural) is tagged limited record Name : String (1..Name_Length); end record; This design is perfectly legal in Ada 2005. Name_Length is hidden because it is nobody's business. Later on, this implementation might be replaced with Unbounded_String or whatever. Now the implementation of Create goes as follows: function Create (Name : String) return Power_Plant is begin return (Name'Length, Name); end Create; A derived type works fine: type My_Plant is new Power_Plant with null record; function Create return My_Plant is begin return (Power_Plant'(Create ("my plant")) with null record); end Create; As you see your assumptions about implied meanings of (<>) are wrong, at least in Ada 2005. It is OK to have a parent type with (<>) and a constructing function that constructs the parent as necessary without leaking any details about the discriminants and other implementation details of the parent type. Now, the point is that this model of construction does not work with abstract types because of fundamental reasons. It is not (<>) which is broken, but the construction model. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de