Re: Ada.Locales pseudo-string types

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

On 12-08-09 15:17 , Dmitry A. Kazakov wrote:

Niklas:
>>>> 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;

Dmitry:
>>> If arrays had classes you could inherit the Parent's interface which would
>>> bring Print with it.

Niklas:
>> 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.

Dmitry:
> Yes. Either operations are implemented anew or else they are generated per
> composition of a conversion provided by the programmer with the operation
> of Parent.

So in the Child/Parent example, how would you "generate" the Print
operation for Child_Arr? How much more text would that need than the
current work-around, which is:

   procedure Print (Item : in Child_Arr)
   is
      Parents : Parent_Arr(Item'Range);
   begin
      for P in Parents'Range loop
         Parents(P) := Parent (Item(P));
      end loop;
      Print (Parents);
   end Print;

(This work-around becomes longer for operations with "in out" parameters.)

Niklas:
>>>> The operation Print on Parent_Arr is not inherited by Child_Arr,

Dmitry:
>>> Why should it? Child_Arr is unrelated to Parent.

Niklas:
>> 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?

Dmitry:
> type A is range 1..100;
> type B is range 1..100;
> 
> How do you feel them, same, different?

Types A and B are different, but both are related to (derived from)
their (unnamed) 'Base types, and probably A'Base is the same as B'Base,
in which case both A and B inherit all operations of that type.

I don't think this example is similar to the Child/Parent example.

Niklas:
>> 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.

Dmitry:
> This relationship must be stated explicitly, e.g. Child implements the
> interface of Parent = Child and Parent are in the same class with the
> operations so and so defined.

"Must" is your opinion. I can disagree.

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

Niklas:
>> I'm not sure that making the relation manifest in that way is important.

Dmitry:
> How otherwise you could tell if Child could be used with Print?

(I assume you mean whether Child_Arr could be used with Print.) The
answer is: by making it a general language rule that "array of
derived-type" inherits operations from "array of parent-type" when the
index types match.

Dmitry:
> Child must
> be in the class of types having Print. Manifested typing requires this
> declared. It is a contract model.

Contracts (even in real law, I believe) can be implied, and can contain
implied requirements defined by general rules or laws. Whether they
should be manifest (explicitly written out) is a trade-off.

In this case, one should consider the possible harm, such as
ambiguities, coding errors, unreadability, etc. that the implicit
inheritance of (in this example) Print from Parent_Arr to Child_Arr
could cause, weigh it against the benefits, and then decide, based on
one's goals for the language. You consider the harm to be larger than
the benefit; I'm not sure yet.

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