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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ab66185f2bca0483 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-11-15 20:01:38 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeed.berkeley.edu!ucberkeley!sn-xit-05!sn-xit-06!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Extension of non-limited type needs limited component Date: Fri, 15 Nov 2002 21:54:04 -0600 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <2dbd76f3.0211130203.7d2d14fd@posting.google.com> <2dbd76f3.0211140126.5d233e41@posting.google.com> <3vb7tug4h99mmalcn0l5ul18cu0ui6i458@4ax.com> X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:30970 Date: 2002-11-15T21:54:04-06:00 List-Id: Robert A Duff wrote in message ... >"Randy Brukardt" writes: >> I don't recall why you are not allowed to make the extension of the >> limited type non-limited. (I didn't find anything in the AARM on this >> subject.) > >I don't think it would work, because ":=" on a derived type copies the >parent part, which is limited, and therefore not copyable: >... >The assignment above is copying a task, which is bad news. It is also >copying an access discriminant, which is bad news. Also, the component >Self of X is supposed to point at X, and the assignment defeats that. I knew there was a reason, I just couldn't figure out what it was. I'm surprised that this discussion is not in the AARM, because it is such a restrictive rule that you'd think that there would have been a justification for it somewhere. >I suppose it could work if all ancestor limited types are not private. >Then we could add a rule saying that deriving a new non-limited type is >OK if the ancestor types *could have been* non-limited -- that is, they >don't violate any of the rules for non-limited types (e.g., no access >discriminants allowed). > >But that would be a rather severe restriction -- I *want* most of my >types to be private. No, that's not going to work. And, of course, breaking privateness would also be a bad idea (even though it would work in this case. >Here's another alternative: you could invent a new kind of type -- >"pseudo-limited". A pseudo-limited type disallows assignment >statements, but *also* disallows all the things disallowed for >non-limited types. A pseudo-limited type can have pseudo-limited >components, and non-limited components, but not limited components. >Then you could have a hierarchy with the root of the tree >pseudo-limited, with some subbranches being limited and some non-limited >(and some pseudo-limited). That would work, I think. >Sounds complicated. I haven't thought it through, so I'm not at all >sure it even works. But I have to agree with the 'sounds complicated'. I doubt that this problem is severe enough to justify a solution like this. (We've had other problems with simpler solutions shot down, after all.) Randy.