Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!tut.cis.ohio-state.edu!osu-cis!att!pegasus!ech
From: ech@pegasus.ATT.COM (Edward C Horvath)
Newsgroups: comp.lang.eiffel
Subject: Re: First Class Routines [Short but
Message-ID: <2736@pegasus.ATT.COM>
Date: 2 Apr 89 21:27:40 GMT
References: <118100001@p.cs.uiuc.edu>
Organization: AT&T ISL Middletown NJ USA
Lines: 33

From article <118100001@p.cs.uiuc.edu>, by johnson@p.cs.uiuc.edu:
> A highly polished set of classes will not have 'rename' and 'redefine'.
> They are what you use to achieve unplanned reuse.  Once you have a working
> system then you should restructure it to remove the kludges you built
> while you were prototyping.

I must disagree: you might as well say that there's no need for deferred
features.  Overriding the "draw" feature of a subclass of "graphical object"
is the classic example of a function that REQUIRES redefine.  A true
sub-class may also save by using rename as well, to provide access to
the redefined parent feature.

Rename has other uses as well, mainly providing features with more "natural"
names in the new derived class's context.  Disambiguating feature-name
collisions is essential in any case; you might argue that name collisions
are in the nature of a "kludge," but again I must disagree: "create" "print"
and many other "generic" features shouldn't need to be uniquely named across
the entire class space!  Better to name a spade a spade, and distinguish the
two only in classes that both dig holes and play bridge.

That's not to say that, having finished the first draft, there are never
improvements to be made; still, your implicit assumptions only apply to "toy"
projects.  It's unwarranted to assume that one can blithely modify the
interfaces of all the classes one uses.  Even if I do have such access,
if the class library is shared with others, I can't just arbitrarily rename
features (unless I want to maintain EVERYBODY's code -- no thank you!).

Finally, rare indeed is the development project where one has time in the
schedule to go back and "remove the kludges" one introduced.  I'd be more
likely to go back to rename inherited features to be more natural, or
redefine features that didn't QUITE match up with the inherited ones.

=Ned Horvath=