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-14 11:31:25 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!sn-xit-05!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Extension of non-limited type needs limited component
Date: Thu, 14 Nov 2002 13:25:13 -0600
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <ut7u4qe5ef2i69@corp.supernews.com>
References: <2dbd76f3.0211130203.7d2d14fd@posting.google.com>
 <aqtf2s$j6f$1@s1.read.news.oleane.net>
 <2dbd76f3.0211140126.5d233e41@posting.google.com>
 <ar052b$8mc$1@s1.read.news.oleane.net>
 <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:30900
Date: 2002-11-14T13:25:13-06:00
List-Id: <comp.lang.ada>

Dmitry A. Kazakov wrote in message
<3vb7tug4h99mmalcn0l5ul18cu0ui6i458@4ax.com>...
>Which also raises an interesting question, whether T'Class should
>always inherit "non-limitness" of T. Or more generally shouldn't one
>have an ability to disallow primitive operations (like ":=" in case of
>non-limited->limited mutation)?


Of course, Ada has the capability to disallow ":=". It's called (drum
roll) "limited". :-)

This issue was discussed extensively during the Ada 95 design process.
It seems like some way to disallow ":=" is needed, but we kept coming
back to the point that that is what "limited" is for. We certainly don't
need two notions of no ":=".

>...
>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.

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.)

                   Randy Brukardt