micke@sm.luth.se (Mikael Degermark) (01/11/89)
<greeting phrase>
I have recently read the Book by Meyer, and found it very interesting.
Eiffel seems to be a language worth trying, and I hope to be able to do so
in the near future.
When reading about multiple inheritance, there was something which I
wasn`t able to understand at first, and after discussing it with my colleagues
(which didn`t have any solution either), I'm now asking You to help me.
The problem conserns the DRIVER, FRENCH_DRIVER, US_DRIVER, FRENCH_US_DRIVER
example given in the book (no, I haven't got the page reference),
here is a condensed version:
Assume there is a class A that declares and exports a feature f:INTEGER.
Assume there is two other classes B and C which each inherit A.
Assume a fourth class D that inherits both B and C and renames f:
class D export f_b, f_c
inherit B rename f as f_b;
inherit C rename f as f_c;
...
Now, an instance of D has two distinct integer features f_b, f_c.
Consider the following fragment of eiffel: (I hope it is eiffel ;->)
a:A;
b:B;
c:C;
d:D;
...
d.Create;
a := d; -- legal, A is an ancestor to D.
b := d; -- legal, B is an ancestor to D.
c := d; -- legal, C is an ancestor to D.
if b.f = ... -- this should be the same as d.f_b, right?
if c.f = ... -- this should be the same as d.f_c, right?
if a.f = ... -- here is the problem!
PROBLEM: Which of the features d.f_b and d.f_c is denoted by a.f?
The type-checking is supposed to prevent use of undefined features,
but there doesn't seem to be any sensible way to decide which of d.f_a and
d.f_b is denoted by a.f when the dynamic type of a is D.
So, is it d.f_a? or d.f_b? or neither? it couldn't be both, surely?
Actually, I suspect that there will be problems with b.f and c.f also,
consider the implementation.
Hopefully, those of You who have access to a compiler could try it and
tell me how it works. Would also like comments on how it *ought* to be.
Thanks!
Mikael Degermark email: micke@sm.luth.se
Dept. of CS
U. of LULE] (read ] as an A with a ring)
Swedenjimp@cognos.uucp (Jim Patterson) (01/16/89)
In article <203@my2.luth.se> Mikael Degermark <micke@my.sm.luth.se> writes: >Assume there is a class A that declares and exports a feature f:INTEGER. >Assume there is two other classes B and C which each inherit A. >Assume a fourth class D that inherits both B and C and renames f: > > class D export f_b, f_c > inherit B rename f as f_b; > inherit C rename f as f_c; > ... > >Now, an instance of D has two distinct integer features f_b, f_c. > >Consider the following fragment of eiffel: (I hope it is eiffel ;->) > > a:A; > b:B; > c:C; > d:D; > > if a.f = ... -- here is the problem! > >PROBLEM: Which of the features d.f_b and d.f_c is denoted by a.f? a.f will in fact refer to d.f_c. There doesn't seem to be a "theoretical" reason for this; it's more a consequence of the implementation. f_c will be chosen because C's features are initialized in class D after those of B and so override them. An alternative implementation is possible whereby f_b and f_c would refer to the same attribute. In your example, and from a's perspective, this seems to make more sense. However, in other examples, it may not. Consider a class COORDINATE and a class AREA implemented as follows. class COORDINATE FEATURE X,Y : INTEGER; END; class AREA INHERIT COORDINATE rename x as x1, y as y1; COORDINATE rename x as x2, y as y2 END; Here, AREA can refer independently to each of two (x,y) pairs. If the compiler made x1 and x2 refer to the same attribute, this would not be possible. On the other hand, the existing implementation means that COORDINATE will only ever refer to x2 and y2 from an AREA object. This makes it impossible for AREA to share COORDINATE code to deal with x1 and y1. Clearly, there are some weaknesses in the implementation when it comes to multiple inheritence of attributes. No doubt some of this is inherent in the structure (it really is ambiguous whether you mean f_b or f_c). -- Jim Patterson Cognos Incorporated UUCP:decvax!utzoo!dciem!nrcaer!cognos!jimp P.O. BOX 9707 PHONE:(613)738-1440 3755 Riverside Drive Ottawa, Ont K1G 3Z4