From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,1116ece181be1aea
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-09-17 08:34:38 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail
From: Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Is the Writing on the Wall for Ada?
Date: Wed, 17 Sep 2003 17:42:35 +0200
Message-ID: <0hvgmvg9j0tieqr6e5bqcbfhnlvm7n63vi@4ax.com>
References: <mailman.20.1062997816.295.comp.lang.ada@ada.eu.org>
 <q697b.8261$w41.4773@nwrdny02.gnilink.net> <3F5F7FDC.30500@attbi.com>
 <XSR7b.13955$w41.12275@nwrdny02.gnilink.net> <3F6079A9.6080108@attbi.com>
 <568ede3c.0309110925.57d07508@posting.google.com>
 <u9v2mvgt0ih71a8i780bmos6nrik4v23l9@4ax.com> <uy8wq75u9.fsf@earthlink.net>
 <c4gdmvskkdm9hku5arae5ftfpcbijretmr@4ax.com> <3F67B21F.7080303@attbi.com>
NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: news.uni-berlin.de 1063812877 28160549 212.79.194.111 (16 [77047])
X-Newsreader: Forte Agent 1.8/32.548
Xref: archiver1.google.com comp.lang.ada:42618
Date: 2003-09-17T17:42:35+02:00
List-Id: <comp.lang.ada>

On Wed, 17 Sep 2003 01:00:46 GMT, "Robert I. Eachus"
<rieachus@attbi.com> wrote:

>Dmitry A. Kazakov wrote:
>
>> MII suffers same problems as full MI. When you add an interface it may
>> conflict with other interfaces. Adding an interface several times you
>> have the diamond problem: whether same interfaces are mapped to one
>> interface of the new type or to different cloned interfaces.
>
>The current write-up deals with the diamond problem as follows:
>
>If you inherit operations from two types with the signature, if one is 
>from the (direct) parent, that is the one used.  If the two are from 
>different interfaces, then calling that operation is ambiguous.

But actually one need all possible mappings 2->1 and 2->2, and in case
of n-th inheritance n->m. The diamond problem is a fundamental one,
which cannot be eliminated.

>So you can get around the diamond problem by directly inheriting from 
>one interface and only inheriting the interface of the other.  Yes, it 
>isn't perfect, but there is one full solution to the problem.  (With 
>mix-ins, the order of inheritance determines which operation is visible 
>for the final type, but you can alway either use renaming to make the 
>hidden operation visible, or call it directly using type conversions.)

Yes, but renaming + optional type conversions would be an universal
solution for full MI too.

BTW, one could require to name the bases as we are doing in case of
subroutine parameters:

type T_1 is ...;
type T_2 is new T_1 with ...;
type T_3 is new T_1 with ...;
type Diamond is new A : T_1,  B : T_2, C : T_3 with ...;
for Diamond.B.T_1 use Diamond.A;  -- All instances of T_1 are
for Diamond.C.T_1 use Diamond.A;  -- same

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