Re: Ada.Locales pseudo-string types

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 12-08-09 10:48 , Dmitry A. Kazakov wrote:
> On Wed, 08 Aug 2012 17:01:23 +0300, Niklas Holsti wrote:
> 
>> On 12-08-08 14:59 , Dmitry A. Kazakov wrote:
> 
>>> BTW, if you go that far you should also allow conversions between any array
>>> types of convertible elements. E.g. between arrays of floats and arrays of
>>> integers etc.
>>
>> Well, for explicit value conversions, why not? But I don't think that
>> there is significant need for such conversions on the array level.
> 
> I needed to convert array of access types in some cases. But I agree that
> there is no significant need in array conversion, in any array conversion,
> I would add. Don't we consider conversions bad, in Ada? If so, we should
> rather eliminate cases where conversions are needed, rather than inventing
> more and more sophisticated ways of conversion.

I think that conversions are the logically right thing in some cases,
while more inheritance (which I assume is your aim) is better in other
cases. I would not like to reduce the conversion abilities of Ada.

>> What I have sometimes found annoying is that operations on arrays of a
>> parent type cannot easily be applied to arrays of a derived type.
>> For example:
>>
>>    type Parent is (A, B, C);
>>    type Parent_Arr is array (Positive range <>) of Parent;
>>
>>    procedure Print (Item : in Parent_Arr)
>>    ...
>>    end Print;
>>
>>    type Child is new Parent;
>>    type Child_Arr is array (Positive range <>) of Child;
> 
> If arrays had classes you could inherit the Parent's interface which would
> bring Print with it.

It is not clear to me how that would work, in detail. Either one would
have to override all the operations for Child_Arr, to substitude Parent
with Child, or there would have to be some implicit rules for such
substitutions, which would in effect establish the same implicit
relationship between Child_Arr and Parent_Arr as I feel already exists.

>> The operation Print on Parent_Arr is not inherited by Child_Arr,
> 
> Why should it? Child_Arr is unrelated to Parent.

It is just a feeling, and sometimes a practical need. Surely Child_Arr
is in some sense related to Parent_Arr, since Child is related to
Parent, and the same type construction (array) is used in both?

If a Child is-a Parent, in the sense that primitive operations for
Parents are also available (inherited) for Children, why are not
operations on collections of Parents available for collections of
Children? A collection (array) of Children is-a collection of Parents.

(This relationship could be easier to see and implement if Ada had a
"sequence" type construction in addition to the "array" type
construction, because then we would not have to consider the possible
difference in the index types of Child_Arr and Parent_Arr. That is, if a
list of elements of type T could be defined as "sequence of T" without
having to choose a specific type and range to index the sequence.)

> Somewhere in its
> declaration Child_Arr must say "new Parent" or "and Parent." Such type
> relationships must be manifested, not implied.

I'm not sure that making the relation manifest in that way is important.
I think that an Ada-derived language could be defined that would let
Child_Arr inherit Print from Parent_Arr, without requiring this manifest
relation in the syntax. Other considerations (readability, reliability)
would determine the decision.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .