Re: Extension of non-limited type needs limited component

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Randy Brukardt" <randy@rrsoftware.com> 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