Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdahl!uunet!mitel!sce!cognos!kain
From: kain@cognos.uucp (Kai Ng)
Newsgroups: comp.lang.eiffel
Subject: Re: redefinition and renaming
Keywords: redefinition, renaming, dynamic binding
Message-ID: <5434@corona.UUCP>
Date: 3 Mar 89 23:16:13 GMT
References: <2431@isis.UUCP>
Reply-To: kain@cognos.UUCP (Kai Ng)
Organization: Cognos Inc., Ottawa, Canada
Lines: 164

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''.

 Please see below.
 N.B. In case somebody don't know, if you have an early version of the book,
      the header of the table which reads cl.f, dl.f dl.f' should be corrected
      to al.f, bl.f & bl.f' respectively.

>Is this a typo, an implementation fact of the system which isn't
>supposed to be consistent, or am I simply missing the point?  My
>conceptual model of dynamic binding leads me to expect that a1.f and b1.f
>should agree when the latter is "legal".  I don't have an eiffel system
>to test the table entries.

 As far as I know, that table is still correct to me.
 Almost all combinations have been used in our own implementation of
 Eiffel Object Library.

>I realize that there may rarely (never?) be any reason to use row 6
>but I appreciate any clarification.

 This is just a start. When multiple inheritance comes into place, life is a
 lot more complicated. (Features of same name from different parents,
 same feature from different parents with different implementations orignated
 from the same grandparent, etc.) I've found rename and redefine in
 multiple inheritance is not described clear enough in the book.

>As this may be a rather esoteric question and/or my obvious 
>misconception, please respond by e-mail to mmartin@ducair.bitnet and I
>will post interesting responses.

 I find my way of memorizing the effect of renaming and redefining is easy,
 better than intepreting that table everytime, and probably is useful to many
 people, hence I go ahead and post it.

-------------------------------------------------------------------------------

 The original table on p.260 of Object-oriented Software Construction by
 Dr. Meyer.

                           a.f           b.f          b.f'

 1. f not redefined        Q             Q            illegal
    f not renamed

 2. f not redefined        Q             illegal      Q
    f renamed f'

 3. f redefined Q'         Q'            Q'           illegal
    f not renamed

 4. f redefined Q'         Q'            Q'           Q
    f renamed f'

 5. f not redefined        Q''           illegal      Q''
    f renamed f'
    f' redefined Q''

 6. f redefined Q'         Q''           Q'           Q''
    f renamed f'
    f' redefined Q''

-------------------------------------------------------------------------------

 The Game:
   There is a class B which is a subclass of A; there is an instance b
   of type B and b is also referenced by a of type A. That is, the dynamic
   type of a is indeed B. We have to determine which version of a feature
   f is actually used if f is renamed and redefined in the subclass.

 Notation:
   [f/Q] - feature of name f and implementation Q.

 Rules:
   1. Construct a table starting with [f/Q].
   2. In case of renaming (f to f'), place [f'/Q] to the right of the [f/Q]
      being renamed.
   3. In case of redefining (Q to Q'), place [f/Q'] in the bottom of the
      [f/Q] being redefine; if there is an entry to the left place it one
      more line down, etc.
   4. After all the renaming and redefining is done, the feature accessible
      by the superclass instance 'a' is always the bottommost one and the
      left one has precedence (and always of name f).
      The feature accessible by the subclass instance 'b' are all the
      ones reachable from the right. In case there are more than 1 in
      the same column, the bottom one has precedence.


 Case 1 (as in the table):

     [f/Q]   <-- b.f

       ^
       |
       a.f

 Case 2:

     [f/Q]   [f'/Q]   <-- b.f'

       ^
       |
       a.f

 Case 3:

     [f/Q]

     [f/Q']   <-- b.f

       ^
       |
       a.f

 Case 4:

     [f/Q]    [f'/Q]   <-- b.f'

     [f/Q']            <-- b.f

       ^
       |
       a.f

 Case 5:

     [f/Q]   [f'/Q]

             [f'/Q'']   <-- b.f'

                ^
                |
                a.f

 Case 6:

     [f/Q]    [f'/Q]

     [f/Q']              <-- b.f

              ['f/Q'']   <-- b.f'

                ^
                |
                a.f



 Hope all these help.
 Happy OOP
-- 
Kai Ng                 P.O. Box 9707         UUCP: uunet!mitel!sce!cognos!kain
Cognos Incorporated    3755 Riverside Dr.
(613) 738-1440         Ottawa, Ontario,
 ext. 6114             CANADA  K1G 3Z4