Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!yale!mfci!genly
From: genly@mfci.UUCP (Chris Hind Genly)
Newsgroups: comp.lang.eiffel
Subject: Re: redefinition and renaming
Keywords: redefinition, renaming, dynamic binding
Message-ID: <694@m3.mfci.UUCP>
Date: 7 Mar 89 02:53:48 GMT
References: <2431@isis.UUCP> <5434@corona.UUCP>
Sender: genly@mfci.UUCP
Reply-To: genly@mfci.UUCP (Chris Hind Genly)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 61

In article <5434@corona.UUCP> kain@cognos.UUCP (Kai Ng) writes:
>In article <2431@isis.UUCP> mmartin@isis.UUCP (Mike Martin) writes:
>>I am having difficulty understanding Figure 11.1, p. 260, in the second
>>printing of Meyer's book.  
>
>  Me too. It took me quite a while to comprehend that table.
>  My understanding of it is mostly gained from experience in using Eiffel.
>
>>It seems to me that there is an inconsistency between row 4 and row 6
>>in the column headed a1.f (where the dynamic type of a1 is B).  In
>>particular I can make sense of the table if the a1.f entry in row 6 were
>>phi' instead of phi''.
>

I too had trouble with this table.  I also believe it to be
inconsistant.  However I have the suspicion it is correct.  Here are
the principles I expected to be used to build the table:

1)
	class B inherit
	 A rename f as f';
	 ...
	end


  Implies f:A and f':B invoke the same feature.  Where f:A means
  feature name f in A. In additon if no definition is supplied
  for f' in B, then f:A will be used.  Unless explicitly defined there
  will be no f:B.  I imagine the absence of the rename is the same as
  "rename f as f".  Where the first f is talking about A, and the
  second f is talking about B.


2) Redefined appears to be straightforward.  Whatever definition is
 given in B for a feature name is the one invoked by that name.


This first principle above is at odds with row 4 of the table in the book.
This is what I expect row 4 to be.

4. f redifined Q' 	Q	Q'	Q
   f renamed f'

The following quote from the book leads me to believe this unexpected
row definition was intentional.

  Case 4 is like case 3; but here the original implementation Q,
  defined in A, is still needed in b.  This often occurs because the
  algorithm for Q' internally calls the algorithm for Q. Without
  renaming, there would be no way to refer to Q within B, as the name
  f now denotes Q'.  Renaming makes it possible to keep the old
  version available under a different name.

But it seems like a wart to me.  I would have preferred another mechanism
to get at Q.  Perhaps something like.

	class B inherit
	 A reinherit f as f'

Which would cause the feature named f' in B to be inherited from f in
A.  But it says nothing about what a.f invokes.