Re: Ada.Strings.Bounded

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

On Sat, 05 Apr 2008 11:43:39 +0200, Pascal Obry wrote:

> Works fine! But then it becomes a bit messy when converting back and 
> forth with the string type.
> 
>     U1 := To_Unbounded_String ("whatever");
> 
>     Put_Line (To_String (U1));
> 
> Not a big deal, but if we can find a nice way to tell that such routine 
> must be used for conversion between type it will be quite handy.
> 
>     type Unbounded_String is ...;
> 
>     function To_String (U : Unbounded_String) return String;
> 
>     for Unbounded_String'Conversion (String) use To_String;

No, that would be a can of worms. Arbitrary type conversions automatically
applied is a mess. Below you immediately spot the problem of conversions
preferences. Because conversions are arbitrary, there is no any order
defined on the types to make a choice.

What is actually needed is to say that Unbounded_String is a member of
String'Class and you wanted to inherit everything form String.

The implementation of inheritance (by the compiler) will require you to
provide two *private* conversion functions when the types are untagged.
Note that you need two conversions: a forward conversion for in-parameters
and a backward conversion for out-ones. In out parameters will use both
(copy-in, copy-out).

For tagged [actually, by-reference] types the compiler can generate
conversions because they are necessarily view conversions.

> Just to get the idea, then one could write:
> 
>     Put_Line (U1);
> 
> Of course this raises some questions:
> 
>     What to do if we have Put_Line defined for String and
>     Unbounded_String? Which version gets called?

It will one of Unbounded_String, because that will be an override.

Note though, that Put_Line (File, String) will open further questions. Is
it primitive in File or in String? Clearly it should be in both. This is
how multiple dispatch issue comes in.

> Anyway that's just some wild thoughts :)

It is not wild, it is how Ada types system should be completed.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de