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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,5d4ade2fd8fd67c6 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!138.195.8.3.MISMATCH!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Legit Warnings or not Date: Tue, 2 Aug 2011 16:30:24 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <531193e0-3305-4292-9ed8-0176226c1d00@x12g2000yql.googlegroups.com> <1rx6dwrxmc81p.eazb4fjqztox$.dlg@40tude.net> <1hi6gva8jhf7o.tq1yp29jn3qu.dlg@40tude.net> <110nibt4tsn7q.162t6eli286tt.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1312320636 11506 69.95.181.76 (2 Aug 2011 21:30:36 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 2 Aug 2011 21:30:36 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Xref: g2news1.google.com comp.lang.ada:20449 Date: 2011-08-02T16:30:24-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:110nibt4tsn7q.162t6eli286tt.dlg@40tude.net... > On Mon, 1 Aug 2011 17:12:23 -0500, Randy Brukardt wrote: ... >> > 4. Why a built-in implementation of array of S'Class (what you seemed >> to be >>> arguing for) should be easier/more efficient/more compatible to Ada than >>> an >>> implementation trough Ada.Container only publicly visible as an array? >> >> There is no new magic needed to allow S'Class as a component type -- only >> the removal of a single legality rule (much like Ada 2005 eliminated the >> library-level requirement on derived tagged types). > > That is because your compiler already implements this magic. Other > compilers may have problems with that. True enough, but that surely was true for removing the library-level requirement -- no compiler had that magic. My point was that such a change does not change the model of the language at all -- the only cost (admittedly, not trivial) would be for implementations. > And for a programmer the problem is to have control over the constraints > (when the tag can be changed and when not) and over copying (when dynamic > components get copied, when shared). You will need a lot of new keywords > and syntax constructs to specify all possible and needed combinations of > these, plus terrible rules about how these constraints are propagated upon > composition and inheritance. What happens in generics etc. That's taking a simple change and making it far more complex. I'm suggesting changing 3.6(10) [only] to allow S'Class. Nothing further, and this isn't making any attempt to allow more of anything else. Indeed, allowing this would have to be tied to eliminating the bogus possibility of having partially constrained S'Class subtypes. (The vast majority of compilers don't support this possibility, even though the language insists on it). Thus there are no constraints to "have control over". Either you are allowing changing the object to anything in the class, or you are not allowing it to be changed at all. No middle ground there. And there is no "control over copying". These are normal "parts" of the object, and they're always copied. If you don't want copying, then you need to use some sort of reference (cursor or access type). (Of course, an implementation can always do an "as-if" implementation, but the model is always deep copying.) There is no need or value to trying to go beyond that. "Shallow copying" is nasty; pretty much the only value is for performance reasons and it is best to leave those to the compiler. (Premature optimization and all of that.) > To me it is just an overkill. Ada already suffers a plethora of > unorganized > special cases of types instead of a clean and *small* type system. This would *eliminate* some of the special cases (allowing more types unfettered as components and objects). Ada is at the point in its life where only incremental changes can happen -- so redoing the Ada type system isn't happening. Randy.