 |
Newsgroups: comp.lang.ada
From: "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
Date: Wed, 9 May 2012 10:02:50 +0200
Local: Wed, May 9 2012 4:02 am
Subject: Re: What would you like in Ada202X?
On Tue, 08 May 2012 22:20:21 +0300, Niklas Holsti wrote:
No, they must be inherited exactly same way The new operation has the
> On 12-05-08 12:03 , Dmitry A. Kazakov wrote: >> On Tue, 08 May 2012 02:18:28 +0300, Niklas Holsti wrote: >>> On 12-05-07 10:49 , Dmitry A. Kazakov wrote:
>>>>> On 12-05-06 22:28 , Dmitry A. Kazakov wrote:
>>>>>> Yes, for tagged types operations which are unsafe to inherit are inherited
>>>>> The same could be done also for extension by deepening, but it is not
>>>> What are you going to do with user-defined operations?
>>> As distinct from what? Predefined operations? Why should there be any
>> Because if you inherit them, you get all substitutability problems you
>> procedure Foo (X : out Message_Kind1) is
>> But you already answered below than you want to disallow all out and in-out
> Yes, so Foo would not be inherited under that strict rule.
> Perhaps the derived "deepened" type could inherit operations with "out" parameter of derived type when inherited, that is covariance. When an in operation is inherited it too has the parameter of the derived type, which is then converted and passed to the inherited body. For out-operations you call the inherited body and then convert the result. For in-outs, you convert-in, call, convert-out. You might mean that composition with conversion could be inappropriate
Note also, that if exceptions were contracted, he would not be able to use
>>> My suggestion for derived enumeration types that extend the parent type
(See how quickly multiple inheritance slips in? (:-))
>>> (by "deepening") would create derived types (in the Ada sense), not >>> subtypes (in the Ada sense). Thus any user-defined (primitive) >>> operations for the parent type (except those with "out" parameters of >>> that type, as already discussed) would be inherited (redeclared) for the >>> derived type and implemented with automatic conversion of "in" parameters. >> This would exclude all functions returning values of the type. In
> Of course the derived "deepened" type must have these operations, since > but I would not consider them as "inherited" The probe question is: do they overload or do they override.
> (except in the sense that the parent type also has operations with the > corresponding names and uses). covariant <=> overrides <=> inherited <=> method <=> primitive operation
contravariant <=> overloads <=> not-inherited <=> free function <=>
>>>> they
OK, that is consistent. This is exactly the model we have for tagged types
>>>> get automatically inherited in any context where visible. [This in effect >>>> makes you exposed to "class-wide" programming with subtypes even if you >>>> don't want to. All subtypes of a type form a class with ad-hoc operations >>>> gathered from all members, when visible.] >>> Could you give an example, preferably using the types Message_Kind1 and
>> So far it is clear, except for:
>> 1. Distinction between primitive and non-primitive operations. Are all
>> package P
> I assume Q (below) has "with P; use P;".
>> package Q is
>> with P, Q; use P, Q;
> I assume you meant "procedure R is" here.
>> X : Detailed_Message_Kind;
> I would say illegal. The potentially inherited operations should be the > type Detailed_Message_Kind is new Message_Kind1;
> and the only difference should be the treatment of "out" and "in out" - embedded tags. This is why it makes no sense to implement it for specifically enumeration
>> 2. Double-dispatch / multi-methods. What happens with operations which have
You will have to solve MD problematic as well. E.g.
>> several parameters of the parent type: >> procedure Set (X : in out Message_Kind1; Y : Message_Kind1);
>> This is inherited in Y, but not inherited in X. Will it become
>> procedure Set (X : in out Message_Kind1; Y : Detailed_Message_Kind);
> Yes, that could be a way to (weakly) inherit operations with "out" or type T1 is (...);
type S1 is new T1 with ...;
X1 : T1;
> I'm sure there are complications to sort out. I haven't thought very Second to this! Instead of perpetual hand waving about compatibility and
> long or deep about this. If people are interested in this idea, it would > motivate some effort on it. imaginary evils of MI, we, Ada community, should consider how to sort the mess out. > I would like to make the "deepening" derivation as similar as possible With the problems solved you will get enumeration extension for granted.
> to the derivation of enumeration types in Your proposal rounds about how to generate conversion functions. You can generate in-conversion, but cannot out-conversions. The case of plain extension has the opposite problem: in-conversions are impossible. But the mechanics of all this is same: interface inheritance, delegation of some inherited operations to the parent's body composed with a conversion. Semantically, there always will be some issue with conversions, because any
-- You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||