Re: Extension of non-limited type needs limited component

["Randy Brukardt" <randy@rrsoftware.com>]

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