Re: U : Unbounded_String := "bla bla bla"; (was: Is the Writing...)

["Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru>]

Dmitry A. Kazakov wrote:

> >  type Y is private envelope of X;
> >
> [...]
>
> Looks similar to my proposal for defining subtypes.

I think yes, there is much in common, although there is also a difference:
your proposal is significantly broader; it is certainly heavier as it pertains
to possible consequences, and I have no immediate opinion whether it will be
easier to find sound applications for that your proposal than for mine, more
narrow one.

> Why to call "envelope" something which is a subtype? (:-))

"subtype" in Ada implies a possibility of some kind of restriction imposed on
the base type, while the word "envelope" implies some kind of extension (of
functionality or applicability). You see, for a language terms I strongly
prefer application/user view to a compilation theory's view, even for advanced
entities/constructions.

> It should be something like:
>
> type Y is private subtype X;
>
> Note that for the sake of genericity one need more than two
> conversions. There should be four:
>
> X_From_Y, X_To_Y - this pair is used when an Y gets substituted for X,
> i.e. when Y *inherits* a subprogram from X. One of these conversions
> might be absent. Then Y becomes an in-subtype or an out-subtype of X:
>
> type Y is private in subtype X;
>   -- Only in-subroutines are inherited. So only X_From_Y has to be
>   -- defined
>
> Y_From_X, Y_To_X - this pair is used when X gets substituted for Y,
> i.e. when Y exports something to X. This is a way to create 
> supertypes.
>
> type Y is private in out supertype X:

Well, it seems that your proposal uses basic diagrams while mine is restricted
to isomorphic representations.

> If all four conversions are present both types become fully
> interchangeable, which is actually required in case String vs.
> Unbounded_String.

I don't see why two conversions (which provide isomorhic representation)
aren't enough for String vs. Unbounded_String... if we have no intention to
extend current functionality (except of making implicit conversions possible).



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia