Re: What would you like in Ada202X?

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

On Thu, 26 Apr 2012 08:19:41 -0700 (PDT), Adam Beneschan wrote:

> On Wednesday, April 25, 2012 7:52:52 PM UTC-7, Randy Brukardt wrote:
>> "Yannick Duch�ne (Hibou57)" wrote in message 
>> news:op.wdcj0snyule2fv@douda-yannick...
>> ...
>>>> If method resolution clause exists:
>>>>
>>>> type T is new I1 and I2;
>>>> overriding(I1.X) procedure X1 (Obj : T);
>>>> overriding(I2.X) procedure X2 (Obj : T);
>>>
>>>The above may still present issues with overloading. Imagine X exist with 
>>>multiple signatures, for both I1 and I2: as your proposal does not refer 
>>>the precise signature, this would still be ambiguous.
>> 
>> Right; simple names are never enough. You always need the full profile, else 
>> you still have holes. Those holes were bad enough for pragmas that we dumped 
>> the entire mess and invented aspect specifications for Ada 2012.
>> 
>> We actually considered something like this for Ada 2005, but decided it just 
>> goes too far. In part, that's because having such a problem suggests bad 
>> design somewhere: it should never be the case that you have two routines 
>> with the same name and profile that have different meanings.
> 
> I'm not sure that's an indicator of bad design, in this case.  It seems
> quite plausible that the interface types, I1 and I2, were designed by
> people who had nothing to do with each other, working on totally different
> open-source projects; and it happened that they came up with the same name
> and profile for one of their methods.

It gets promptly forgotten that the idempotent model of inheritance is not
the only one. It is absolutely legitimate to implement exactly same
interface twice or more times under an additive model. As an example,
consider the interface of a doubly linked list.

   type Request is new List and List;
      -- A request participates in two lists!

The point is, a properly designed MI shall support *both* models in all
possible combinations of. It is up to the programmer to choose the model in
each concrete case.

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