🚀 go-pugleaf

In article <10691@watdragon.waterloo.edu>, akwright@watdragon.waterloo.edu
(Andrew K. Wright) writes [in response to my earlier posting]:
> 
> This seems to me to be a bug in the compiler.  However, whether your
> example is also incorrect is not made entirely clear in the book.
> The problem is the meaning of "rename": if you are renaming
> f1 as f3, does this mean that you can now define your own f1
> without a redefine clause?
> 
By everything I can get my hands on, "rename f1 as f3" means that the
name "f1" no longer is defined in the class.  Eiffel allows me to define
a new "f1" as in my example.  Further experiments show that the new
definition of "f1" can have arguments and a type entirely incompatible
with the inherited "f1" which has been renamed.  All the evidence suggests
that within the subclass, the name "f3" has taken over all the meanings
inherited from "f1" in the parent class, and left the name "f1" totally
unused.  This is what I would naturally expect "rename" to mean, and nothing
Meyer has said about the semantics of rename suggests differently.

I am more and more convinced that there is indeed a bug in the Eiffel
implementation, and not in the language or in my understanding of the
language.  I think the bug is simply that in the presence of renaming
the feature "lookup" mechanism doesn't always find the appropriate feature.
I have additional examples that illustrate this, which I may post in a few
days.

Dave Robbins                    GTE Laboratories Incorporated
drobbins@gte.com                40 Sylvan Rd.
...!harvard!bunny!drobbins      Waltham, MA 02254