db@lfcs.ed.ac.uk (Dave Berry) (03/11/90)
I intend to make this the last message that I post concerning the Eiffel inheritance hierarchy (apart from follow-ups). I hope these messages have successfully shown some gaps in the published descriptions of the language, and perhaps have included a useful idea or two. I certainly hope that I haven't upset anyone by posting my thoughts on Eiffel. It's an interesting language & I like it. I've often seen articles here asking how to resolve the amiguity that occurs when a feature f is repeatedly inherited under different names. If an attribute a with the type of the ancestor class is assigned an object of the descendant class, then a.f could refer to either copy of the inherited attribute. class A feature f, g class P1 class P2 inherit A inherit P2 rename f as p1_f rename f as p2_f rename g as p1_g rename g as p2_g class D inherit P1, P2 There are three places that this ambiguity could be resolved. 1. At the point of call. This is not satisfactory, because we may not know the dynamic type of the object. Having to know the dynamic type would negate the whole point of object-oriented programming. 2. When the descendant object is asigned to the ancestor variable. This is the approach used in C++. However, its implementation in C++ is in terms of the entire class; whereas in Eiffel we might want to inherit some features via one route and some via another. A possible syntax for this approach is a := d with f = p1.f, g = p2.g; 3. In the definition of the class. This avoids the syntax above, but has the disadvantage that the choice is fixed for all uses. A possible syntax for the third approach is: priority p1_f, p2_g; where p1_f is the name of f as inherited from p1 and p2_g is the name of g as inherited from p2. Probably the most flexible approach is to combine 2 & 3, where the default decision made in the definition of the class can be overridden for a particular assignment. Comments? Dave Berry, LFCS, Edinburgh Uni. db%lfcs.ed.ac.uk@nsfnet-relay.ac.uk "The thought of someone sharing one's own preferences without also sharing one's aversions strikes most people as utterly inconceivable." - C. A. Tripp.
jacob@gore.com (Jacob Gore) (03/12/90)
/ comp.lang.eiffel / db@lfcs.ed.ac.uk (Dave Berry) / Mar 11, 1990 / > class A > feature f, g > > class P1 class P2 > inherit A inherit P2 > rename f as p1_f rename f as p2_f > rename g as p1_g rename g as p2_g > 3. In the definition of the class. This avoids the syntax above, but > has the disadvantage that the choice is fixed for all uses. > > A possible syntax for the third approach is: > > priority p1_f, p2_g; Doesn't class D inherit P1, P2 rename p1_f as f rename p2_g as g do what you want? Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob