Re: Extension of non-limited type needs limited component

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

Robert A Duff wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
> 
>> In an OO language like Ada 95 is, "limited" makes little sense,
>> because it covers only one of many useful alternatives.
> 
> But non-limited/limited does not just mean assignment
> allowed/disallowed.  How do you propose to deal with all the other
> things controlled by this distinction?  For example:
> 
>     Non-limited types can have unconstrained aliased components; limited
>     types cannot.
> 
>     Limited types can have access discriminants; non-limited types
>     cannot.
> 
>     Limited types can have limited components (like tasks and protected
>     objects); non-limited types cannot.
> 
>     The current instance of a limited type is aliased, so you can say
>     "T'Unchecked_Access" inside type T, to make a pointer to the current
>     object of type T.  You can't do that for non-limited.
> 
>     (Most) limited types are guaranteed to be passed by reference;
>     that's not true for non-limited.
> 
>     A function can construct a new object of a non-limited type, and
>     return it.  You can't do that for (most) limited types.

All that are more or less decoupled things. Why should we tie all of them 
under one roof?

> The point is that there are some things you can do for limited that you
> can't do for non-limited, and vice-versa, so neither is a subset of the
> other.  Therefore, you can't derive a limited type from a non-limited
> type, nor vice-versa.
> 
> By the way, have you read the AARM annotations that explain why we
> didn't allow user-defined ":=" procedures?

Yes, however it was some 2 years ago, so will re-read it again.

> We certainly wanted to,
> but we couldn't figure out how to make it work, so we invented Adjust,
> which is not as powerful.  I'd be interested in hearing better ideas
> (even though it's probably too late).

I think that Adjust maybe is just fine. The actual problem is an attempt to 
hide everything from the programmer. Copy+Adjust is a copy constructor, 
fine, but why ":=" should be *always* generated out of it? In my view there 
should be a way to decouple them, i.e. to get rid of the predefined ":=", 
and to define a new one. If a programmer does it, it is now his 
responsibility to ensure that the semantics of ":=" be better close to 
Copy+Adjust. To diminish the consequent mess with inheritance of ":=", one 
could say that if the right parameter is not class-wide, then it is 
covariant, so ":=" has to be either overridden or else disallowed in any 
derived type. [However, I am afraid, that to correctly deal with it one 
would need multiple dispatch anyway.]

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