NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/object/2954

Internet Message Format | 1992-07-21 | 3.7 KB

Xref: sparky comp.object:2954 comp.lang.c++:11273
Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!caen!kuhub.cc.ukans.edu!parsifal.umkc.edu!vax1.umkc.edu!kramasamy
Newsgroups: comp.object,comp.lang.c++
Subject: Re: Multiple Inheritance: `mix-in' classes and derived types
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 21 Jul 1992 19:56:46 GMT
Sender: [e-mail] (Parsifal Administration)
References: <[e-mail]>
Organization: University of Missouri - Kansas City
Lines: 107

In article <[e-mail]>, [e-mail] (Oscar Bosman) writes:
>
> I have a design based upon some abstract classes (A, B, C, D, ... in the
> diagram below) which I would like to mix and match to make my concrete
> classes (L, M, N in the diagram).  So far this a standard 'mix-in'
> design.
>
>         A B  C  D E ...
>         |\  /|   /|
>         | \/ |  / |
>         | /\ | /  |
>         |/  \|/   |
>         L    M    N ...
>
> The problem occurs when I wish declare a function which operates on
> all classes derived from both `A' and `C'.  Ideally I'd like to say
> something like (in modified C++ syntax):
>
>      foo(A & C my_obj) { ... }
>
> where `&' indicates a kind of intersection of types.  I can see two
> ways to do fudge this, neither of which I like.
>
> 1.  I could declare all the combinations of the `mix-in' classes (A_B,
> A_C, B_C, ..., A_B_C, ...) and insist that concrete classes are
> derived from the appropriate `combination' class.  But this is counter-
> intuitive and makes it tedious to add new mix-ins.
>
> 2.  I could declare the argument to be of one type (say `A') and use
> run-time type checking to check that the argument is also of the other
> type before down-casting to a `combination' class.  In Sather this
> might look like this (I don't think that the proposed type-safe down-
> casting for C++ gives the correct behaviour because I don't want to
> type-check against A_C).
>
> class R is
>
>    foo(a:$A) is
>       assert(pre) a.of_type(C::type) end;
>       a_c: $A_C := a;
>
>       -- do something with the `A' features of a_c
>       -- do something with the `C' features of a_c
>    end;
>
> end;
>
> The problem here is that the compile should be able to type-check the
> argument.
>
> There is a proposal to add `type adoption' to Sather 1.0 which would
> go some way to solving my problems with solution 1 above.  As I
> understand it, it would go something like this:
>
> class A_C is
>    adopts L;  // A_C is now a superclass of L
>    adopts M;  // A_C is also superclass of M
>
>    foo(a:$A_C) is
>       -- do something with the `A' features of a
>       -- do something with the `C' features of a
>    end;
>
> end;
>
>
> Does anyone have some experience with using mix-ins in this way. I'm
> paticularly interested in solutions implemented in C++.
>
> Oscar.
> --
> [e-mail]          Centre for Spatial Information Systems
>                                         CSIRO Div. Information Technology
> phone: [phone]                    GPO Box 664
> fax:   [phone]                    Canberra, 2601.    AUSTRALIA.

    What about doing the following ?

    A  B  C  D  E
    \     /     /
     \   /     /
      \ /     /
       X     /
          / \   /
         /   \ /
    L     M

    Derive an abstract class X from 'A' and 'C' and all the classes which derive from both
A and C will derive from X hereafter.

    Now your 'foo' function becomes something like the following

    foo( X &my_obj )
    {
        //do something specific to A
        // do something specific to B
    }


    I hope this helps you

-karthik

[e-mail]