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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ab66185f2bca0483 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-11-16 04:39:38 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!fu-berlin.de!uni-berlin.de!dialin-145-254-039-183.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Extension of non-limited type needs limited component Date: Sat, 16 Nov 2002 13:39:15 +0100 Organization: At home Message-ID: References: <2dbd76f3.0211130203.7d2d14fd@posting.google.com> <2dbd76f3.0211140126.5d233e41@posting.google.com> <3vb7tug4h99mmalcn0l5ul18cu0ui6i458@4ax.com> <6bd9tuc40p68a86rlur3hai1qlv54i8985@4ax.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-039-183.arcor-ip.net (145.254.39.183) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1037450376 16028236 145.254.39.183 (16 [77047]) User-Agent: KNode/0.7.1 Xref: archiver1.google.com comp.lang.ada:30980 Date: 2002-11-16T13:39:15+01:00 List-Id: Robert A Duff wrote: > Dmitry A. Kazakov writes: > >> In an OO language like Ada 95 is, "limited" makes little sense, >> because it covers only one of many useful alternatives. > > But non-limited/limited does not just mean assignment > allowed/disallowed. How do you propose to deal with all the other > things controlled by this distinction? For example: > > Non-limited types can have unconstrained aliased components; limited > types cannot. > > Limited types can have access discriminants; non-limited types > cannot. > > Limited types can have limited components (like tasks and protected > objects); non-limited types cannot. > > The current instance of a limited type is aliased, so you can say > "T'Unchecked_Access" inside type T, to make a pointer to the current > object of type T. You can't do that for non-limited. > > (Most) limited types are guaranteed to be passed by reference; > that's not true for non-limited. > > A function can construct a new object of a non-limited type, and > return it. You can't do that for (most) limited types. All that are more or less decoupled things. Why should we tie all of them under one roof? > The point is that there are some things you can do for limited that you > can't do for non-limited, and vice-versa, so neither is a subset of the > other. Therefore, you can't derive a limited type from a non-limited > type, nor vice-versa. > > By the way, have you read the AARM annotations that explain why we > didn't allow user-defined ":=" procedures? Yes, however it was some 2 years ago, so will re-read it again. > We certainly wanted to, > but we couldn't figure out how to make it work, so we invented Adjust, > which is not as powerful. I'd be interested in hearing better ideas > (even though it's probably too late). I think that Adjust maybe is just fine. The actual problem is an attempt to hide everything from the programmer. Copy+Adjust is a copy constructor, fine, but why ":=" should be *always* generated out of it? In my view there should be a way to decouple them, i.e. to get rid of the predefined ":=", and to define a new one. If a programmer does it, it is now his responsibility to ensure that the semantics of ":=" be better close to Copy+Adjust. To diminish the consequent mess with inheritance of ":=", one could say that if the right parameter is not class-wide, then it is covariant, so ":=" has to be either overridden or else disallowed in any derived type. [However, I am afraid, that to correctly deal with it one would need multiple dispatch anyway.] -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de