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,34c2aa33b8bdb1a9,start
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2002-01-11 02:21:05 PST
Path: 
 archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!news.tele.dk!small.news.tele.dk!195.27.83.146!news-FFM2.ecrc.net!news.iks-jena.de!lutz
From: lutz@iks-jena.de (Lutz Donnerhacke)
Newsgroups: comp.lang.ada
Subject: Sugestion to Multiple Inheritance
Date: Fri, 11 Jan 2002 10:20:48 +0000 (UTC)
Organization: IKS GmbH Jena
Message-ID: <slrna3tf3u.kg.lutz@taranis.iks-jena.de>
NNTP-Posting-Host: taranis.iks-jena.de
X-Trace: branwen.iks-jena.de 1010744448 7678 217.17.192.37 (11 Jan 2002
 10:20:48 GMT)
X-Complaints-To: usenet@iks-jena.de
NNTP-Posting-Date: Fri, 11 Jan 2002 10:20:48 +0000 (UTC)
User-Agent: slrn/0.9.6.3 (Linux)
Xref: archiver1.google.com comp.lang.ada:18766
Date: 2002-01-11T10:20:48+00:00
List-Id: <comp.lang.ada>

I'm looking for a design glue to build something like this:

 I have an several (at least two) interfaces with must be implemented
 by the end user (compiler should require implementation). All of them
 build a free(!) depedency tree. The simplest one is:
    
     A -> B     B is an extended A and C is an extended A.
     |    |     D combines both extensions (requiring both).
     v    v
     C -> D
 
 There are (generic) packages requiring special interfaces.

I'd like to use abstract types and class wide programming, but this can't be
done in Ada naturally.

The rationale suggests three solutions in chapter "4.6  Multiple Inheritance":
  - Adding B as a component extension of C to form D.
    This is not possible for abstract types.
  - Mixin Inheritance
    The extensions for B can be implemented as a mixin, but this results in
    diffenent instantions for B and D. So D can not be converted to B.
  - Adding B with access to D as a component extension of C to form D.
    This is not possible for abstract types.

Combining those: 
  - Adding B as a access constraint of C to form D.
    Its possible to define "type D (b_view : access B) is new C;"
    But this requires double instantiation of the complex data structure of A
    and double maintainces of this data structure. So it's error prone.
    It's even not possible to drop D into a B'Class argument, requiring
    multiple implementations of the same algorithm.

In order to overcome the multiple implementations constraint, it's possible
to generalize more and building the using package generic in the A -> C
abstract type and the used mixin for the B functionality.

Better solutions?