Re: MI in Ada 200X

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

Karel Miklav wrote:

> Dmitry A. Kazakov wrote:
>> Wesley Groleau wrote:
>>>>>Mário Amado Alves wrote:
>>>>>
>>>>>>Everybody wants class MI. The reasons it was left out of Ada 95 and
>>>
>>>I don't!
>> 
>> OK. Bill Gates once said that nobody would need more than 64K RAM. Or was
>> it 640K? I do not remember. Anyway, never say never. (:-))
> 
> I don't see how this is related to MI. What do you think about the
> diamond problem and other evils of MI?

Incest? A bad thing, you know. However, I would not call a problem anything 
that can be detected at compile-time. Anyway we have a lot of 
diamond-things in present Ada. Consider:

with Ada.IO_Exceptions;
package B is
   End_Error : exception renames IO_Exceptions.End_Error;
   ...
end B;

with Ada.IO_Exceptions;
package C is
   End_Error : exception renames IO_Exceptions.End_Error;
   ...
end C;

with B; use B;
with C; use C;

procedure D is
   ...
exception
   when End_Error => -- which End_Error?

exception renaming is not 'renaming', but a new view. In C++ terms it is 
sort of "B : public A", not "B : public virtual A" (as a naive programmer 
might think).

> Besides, where do or would you use this feature?

First from the stack: to make a stream object controlled. (*)

> MI might look like a good idea in a simple project, but when things
> start to get messy and you're caught into inheritance net, you can
> forget who your own mother is :) I vote NO for MI and other inventions
> of marketing departments but YES for interfaces.

(*) Ada.Streams.Root_Stream_Type is not a [public] descendant of 
Ada.Finalization.Limited_Controlled.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de