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 13:41:55 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!uunet!sea.uu.net!sac.uu.net!ash.uu.net!world!news From: Robert A Duff Subject: Re: Extension of non-limited type needs limited component User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Fri, 15 Nov 2002 21:41:10 GMT Content-Type: text/plain; charset=us-ascii References: <2dbd76f3.0211130203.7d2d14fd@posting.google.com> <2dbd76f3.0211140126.5d233e41@posting.google.com> <3vb7tug4h99mmalcn0l5ul18cu0ui6i458@4ax.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Organization: The World Public Access UNIX, Brookline, MA Xref: archiver1.google.com comp.lang.ada:30961 Date: 2002-11-15T21:41:10+00:00 List-Id: "Randy Brukardt" writes: > Dmitry A. Kazakov wrote in message > >1. ":=" should dispatch in X:=Y to a disallowed operation, thus raise > >an exception and so refuse to copy the limited components. > > I don't know why this wasn't chosen. It seems better on the surface. > Possibly because of the desire to catch errors at compile-time rather > than run-time. Exactly. > However, that still doesn't solve the problem that we had in Claw. What > we wanted was a limited root window type with non-limited (thus > assignable) controls. That is, something like: > > Root_Window_Type (limited controlled) > Basic_Window_Type (limited) > Root_Dialog_Type (limited) > Modal_Dialog_Type (limited) > Root_Control_Type (non-limited) > Edit_Type (non-limited) > Checkbox_Type (non-limited) > Static_Text_Type (non-limited) > > [We want to be able to copy control objects because our goal was "no > visible pointers required" for the interface.] > > This does not have the classwide assignment problem, because only > Root_Control_Type has ":=", so it isn't possible to dispatch to a > limited type's ":=". > > We ended up making the whole hierarchy non-limited, but this means > implementing assignment for types for which is both a lot of work and > unneeded (such as application windows). Worse, we didn't meet our "no > pointers" goal, because we can't put limited objects into extentions of > application windows. (So you have to use pointers to do that.) > > 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: package Root_Windows is type Root_Window_Type is tagged limited private; private type Root_Window_Ptr is access all Root_Window_Type; type Root_Window_Type(Discrim: access Blah) is tagged limited record Self: Root_Window_Ptr := Root_Window_Type'Unchecked_Access; T: Some_Task_Type; end record; end Root_Windows; package Root_Controls is type Root_Control_Type is new Root_Window_Type with private is not limited; -- I'm inventing syntax here. ... end Root_Controls; X, Y: Root_Control_Type; ... X := Y; -- Bad. 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 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. 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). Sounds complicated. I haven't thought it through, so I'm not at all sure it even works. - Bob