Re: Extension of non-limited type needs limited component

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

On Thu, 14 Nov 2002 13:25:13 -0600, "Randy Brukardt"
<randy@rrsoftware.com> wrote:

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

In an OO language like Ada 95 is, "limited" makes little sense,
because it covers only one of many useful alternatives.

>We certainly don't need two notions of no ":=".

But there are indeed multiple notions of ":=". Let ":=" is exposed as
a normal operation. Then two arguments would give us 4 different
variants [without much thinking about how useful are some of them]:

procedure ":=" (Left : in out T; Right : T);
procedure ":=" (Left : in out T'Class; Right : T);
procedure ":=" (Left : in out T; Right : T'Class);
procedure ":=" (Left : in out T'Class; Right : T'Class);

Same is valid for all operations with several parameters. For
instance, the predefined "=" (Left, Right : T), which cannot be
disallowed with a disastrous result that a user-defined "=" (Left : T;
Right : T'Class) gets overloaded with the predefined one.

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

Yep, LSP again. However, nobody cares about LSP in case of

   X : Positive;

which also shamefully violates LSP and leads to a run-time exception,
should -1 happen to be assigned to X.

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

BTW. Why do not we have constant record members in Ada? Maybe because
there is no true contructors with parameters?

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

This is an opposite this = defining new operations. It should be a
lesser problem (for LSP).

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

A need to generate some predefined assignment?

The whole idea of "limitness" is IMO wrong. Let's expose ":=", default
constructor, copy constructor to the programmer and let he have a
headache! (:-))

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de