home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / object / 2943 next >
Encoding:
Internet Message Format  |  1992-07-20  |  2.8 KB
  1. Xref: sparky comp.object:2943 comp.lang.c++:11206
  2. Newsgroups: comp.object,comp.lang.c++
  3. Path: sparky!uunet!munnari.oz.au!manuel!csis!oscar
  4. From: oscar@csis.dit.csiro.au (Oscar Bosman)
  5. Subject: Multiple Inheritance: `mix-in' classes and derived types
  6. Message-ID: <1992Jul21.030023.4220@csis.dit.csiro.au>
  7. Organization: CSIRO Division of Information Technology
  8. Date: Tue, 21 Jul 1992 03:00:23 GMT
  9. Lines: 74
  10.  
  11.  
  12. I have a design based upon some abstract classes (A, B, C, D, ... in the
  13. diagram below) which I would like to mix and match to make my concrete
  14. classes (L, M, N in the diagram).  So far this a standard 'mix-in'
  15. design.
  16.  
  17.         A B  C  D E ...
  18.         |\  /|   /|
  19.         | \/ |  / |
  20.         | /\ | /  |
  21.         |/  \|/   |
  22.         L    M    N ...
  23.  
  24. The problem occurs when I wish declare a function which operates on
  25. all classes derived from both `A' and `C'.  Ideally I'd like to say
  26. something like (in modified C++ syntax):
  27.  
  28.      foo(A & C my_obj) { ... }
  29.  
  30. where `&' indicates a kind of intersection of types.  I can see two
  31. ways to do fudge this, neither of which I like.
  32.  
  33. 1.  I could declare all the combinations of the `mix-in' classes (A_B,
  34. A_C, B_C, ..., A_B_C, ...) and insist that concrete classes are
  35. derived from the appropriate `combination' class.  But this is counter-
  36. intuitive and makes it tedious to add new mix-ins.
  37.  
  38. 2.  I could declare the argument to be of one type (say `A') and use
  39. run-time type checking to check that the argument is also of the other
  40. type before down-casting to a `combination' class.  In Sather this
  41. might look like this (I don't think that the proposed type-safe down-
  42. casting for C++ gives the correct behaviour because I don't want to
  43. type-check against A_C).
  44.  
  45. class R is
  46.    
  47.    foo(a:$A) is 
  48.       assert(pre) a.of_type(C::type) end;
  49.       a_c: $A_C := a;
  50.  
  51.       -- do something with the `A' features of a_c
  52.       -- do something with the `C' features of a_c
  53.    end;
  54.  
  55. end; 
  56.  
  57. The problem here is that the compile should be able to type-check the
  58. argument. 
  59.  
  60. There is a proposal to add `type adoption' to Sather 1.0 which would
  61. go some way to solving my problems with solution 1 above.  As I
  62. understand it, it would go something like this:
  63.  
  64. class A_C is 
  65.    adopts L;  // A_C is now a superclass of L
  66.    adopts M;  // A_C is also superclass of M
  67.  
  68.    foo(a:$A_C) is 
  69.       -- do something with the `A' features of a
  70.       -- do something with the `C' features of a
  71.    end;
  72.  
  73. end; 
  74.  
  75.  
  76. Does anyone have some experience with using mix-ins in this way. I'm
  77. paticularly interested in solutions implemented in C++.
  78.  
  79. Oscar.
  80. -- 
  81. Oscar.Bosman@csis.dit.csiro.au          Centre for Spatial Information Systems
  82.                                         CSIRO Div. Information Technology
  83. phone: +61-6-2750912                    GPO Box 664
  84. fax:   +61-6-2571052                    Canberra, 2601.    AUSTRALIA.
  85.