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!feeder.news-service.com!newsfeed.straub-nv.de!nuzba.szn.dk!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: Wed, 3 Aug 2011 15:35:04 -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> <1wg90w555yp7f.1lhp1szkc0cu5$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1312403707 30190 69.95.181.76 (3 Aug 2011 20:35:07 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 3 Aug 2011 20:35:07 +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:20457 Date: 2011-08-03T15:35:04-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1wg90w555yp7f.1lhp1szkc0cu5$.dlg@40tude.net... > On Tue, 2 Aug 2011 16:30:24 -0500, Randy Brukardt wrote: > >> 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. > > When I declare > > type A is array (...) of S'Class; > > 1. Are all elements constrained to same specific type? Assuming the model I'm suggesting is adopted, no. > 2. May object types change after being initialized? Yes. These are completely unconstrained entities. > 3. Which rules apply to view conversions, e.g. T'Class (A (10)). Could it > be then assigned to which types, same, others? The same rules as currently for a parameter of S'Class. I would not want to make any changes there, the rules are messy enough as it is. > 4. In which relation are slices of the array and arrays of T'Class when T > is related to S? [Classes of arrays vs. arrays of classes vs. classes of > arrays of classes etc.] Nothing special; there is no attempt to address the issues with inheritance of composition. I don't think those issues *can* be addressed in an Ada-like type system. > 5. I am horrified what kind of "accessibility rules" might get invented > for > passing elements of this "array" here and there. For me, (dynamic) accessibility is a waste of time; it adds overhead, adds a failure hazard, and buys nothing in terms of safety. (I have to use 'Unchecked_Access in 99% of my programs; 'Access fails for one reason or another.) But that's irrelevant; no new accessibility would be needed because there is no new capability here. These are exactly the same as mutable discriminanted objects (i.e.the type has defaults for the discriminants). It would be erroneous to change the tag of a statically bound parameter (just like it is erroneous to change the discriminant in such a case) -- there is no way to avoid that without requiring programmers to effectively ignore all constraints (because they could change), which is too bogus of a model to contemplate. > [The behavior of types upon composition is a very non-trivial issue.] I would not make any change there; to the extent that it is a problem now it would stay that way. >> 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.) > > Which would make the compiler implementation unusable in so many cases. If so, you would be abusing the intent of the feature. It's intended for composition uses only; if you need to represent dynamically changing connections between objects, then you clearly need references of some sort (cursors preferrably, access types otherwise). If, however, you are statically combining objects, then having to manage references explicitly is just busywork -- it harms readability, does nothing for performance, and the like. Obviously, there is a gray area between these -- but you would never to use direct components to represent connections, only composition. Otherwise you are hiding structure; I'm only interested in cases where there is only one object whose parts consist of previously existing objects that will lose their independent identity. Randy.