Re: Ada.Locales pseudo-string types

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

On Thu, 09 Aug 2012 11:31:44 +0300, Niklas Holsti wrote:

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

I disagree. Conversion is bad when its outcome is not evident. Otherwise
there should be no conversion. Considering the cases of many competing
conversions, these should be dealt with using appropriately named
functions. The names should indicate the result.

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

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.

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

type A is range 1..100;
type B is range 1..100;

How do you feel them, same, different?

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

> (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.)

Sequence of T is nothing but an interface (= abstract root type of a
class).

Array has an interface too, which is a sequence of T + random element
access using index + mutability of elements.

There is no need to invent new entities. Everything fits into one model.

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

How otherwise you could tell if Child could be used with Print? Child must
be in the class of types having Print. Manifested typing requires this
declared. It is a contract model. When declared in Parent'Class, the
implementation of Child can be verified before anybody actually tried to
pass Child to Print eons later. Inference is incompatible with contract
driven design, IMO.

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

I don't trust in type inference.

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