Path: utzoo!attcan!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: <5506@corona.UUCP>
Date: 9 Mar 89 16:56:47 GMT
References: <2431@isis.UUCP> <5434@corona.UUCP> <694@m3.mfci.UUCP>
Reply-To: kain@cognos.UUCP (Kai Ng)
Organization: Cognos Inc., Ottawa, Canada
Lines: 110

In article <694@m3.mfci.UUCP> genly@mfci.UUCP (Chris Hind Genly) writes:
>
>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.
>

Yes, it is intentional but I don't feel it is unexpected because that is
what dynamic binding is all about. Indeed it is quite clear from the
following quote from the book (p.260).

  For redefinition: "Can I have a different implementation for f when it is
  applied to entities of dynamic type B ?"

  For renaming: "Can I change the name under which the original (A)
  implementation of f may be applied to entities of static type B ?"

In other words, if B inherits a feature f from A, redefining f in B with
implementation Q' makes sure Q' is used when f is invoked and the dynamic
type is of B;

renaming f, of implementation Q, in B to f' preserves the availability of Q
to B known as f' unless f' is further redefined (as in row 5 and 6).

Hence row 4, no more and no less, is expected as

  f redefined Q'     Q'   Q'   Q
  f renamed f'

Furthermore, I like to point out the order of the RENAME and REDEFINE
clauses is not important if there is only one of each. (I am not 100%
positive if you have more than one of each).



Talking about dynamic binding, I've found in some cases the binding
mechanism in Eiffel is NOT that dynamic. Consider the following example
comprises 4 classes:

------------------------------------------------------------------------
CLASS A

FEATURE

    classNumber: Integer IS 1;

    printClassNumber IS
        EXTERNAL
            printf LANGUAGE "C";
        DO
            printf ("%d", classNumber);
        END; -- printClassNumber

END -- Class A
-------------------------------------------------------------------------
CLASS B

INHERIT
    A REDEFINE classNumber

FEATURE

    classNumber: Integer IS 2;

END -- Class B
-------------------------------------------------------------------------
CLASS C

INHERIT
    A REDEFINE classNumber

    ...
    classNumber: Integer IS 3
    ...
-------------------------------------------------------------------------
CLASS D

EXPORT
    printB, printC

INHERIT
    B RENAME printClassNumber AS printB;
    C RENAME printClassNumber AS printC

FEATURE

END -- Class D
-------------------------------------------------------------------------

However, both d.printB and d.printC will print out the number 3 instead
of 2 and 3 respectively as expected.

Maybe I miss a point in terms of dynamic binding. (Dr. Meyer ?)
-- 
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