db@lfcs.ed.ac.uk (Dave Berry) (03/05/90)
I've just finished preparing a talk on Eiffel, and I think I've found a flaw in the language. I noticed this while working out how to explain the table on p.260. I apologise in advance if I have misunderstood the table myself. The case I'm concerned with is when a class A defines a feature theta and gives in the name f, and a subclass B of A renames f to f' and also defines a new feature theta' and gives it the name f. I.e. class A export f f is <theta> end class B inherit A rename f as f' f is <theta'> end OOSC gives the impression that B needs a "redefine" clause for f. I think that this is wrong, and that a "redefine" clause for f should be an error. My reason is that if a reference a with static type A has dynamic type B, then a.f is synonymous with b.f'. Thus b.f is not redefining a.f; they are independent features that happen to have the same name in different classes. Another way of stating this is to say that "redefine" should only refer to features that can be "called from" a variable with the static type of the parent class. This is what redefinition is for; any changes of name are incidental. I can see that it might be useful to have some indication that references to f in B don't refer to the f in A, but using "redefine" is confusing. I suggest the syntax "define new", e.g. class B inherit A rename f as f' define new f f is ... end. Comments? Footnote: I agree with a comment made here about a year ago, that the table on p.260 would be easier to understand if the renaming "clauses" were placed before the redefinition clauses. This better reflects the order of events when tracing binding information from parent to child, and also agrees with the syntax of Eiffel. 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.