[comp.lang.eiffel] rename, redefine

kain@cognos.uucp (Kai Ng) (03/15/89)

Article posted for Mr. Roger Rousseau

*******************************************************************************
From sce!mitel!uunet!mcvax!mirsa.inria.Fr!rr Tue Mar 14 02:52:16 1989
From: Roger Rousseau <sce!mitel!uunet!mcvax!mirsa.inria.Fr!rr>
To: cognos!kain
Subject: Re: redefinition and renaming
News-Path: inria!mcvax!uunet!mitel!sce!cognos!kain

==========
I can't yet write on eiffel news. Below is an answer about this subject.
Can You post it on eiffel news?
Thanks
=========

1. An error in the table of the page 260 of The book ?
------------------------------------------------------

Effectively, this table is not very clear and perturbs my students too.
Moreover, the current implementations (v2.1, at least Sun and Vax/Ultrix)
differ from this table for the last row (#6): at first column (a1.1), we
observe PHI' not PHI''.
So, is it an error of The book or of the implementations?

Unfortunately, the explanations for this case #6 (p261) aren't very clear too:
>    Finally, in case 6, everything is combined: we need a specific B
> implementation of the feature, we want to refer to it locally under a new
> name, but we still need access to the original version.

Thus, with the same notations as in this table (p260)
    a1: A; b1: B; (an heir of A); b1.Create; a1:= b1
    and "x->y" means "x refers to y",
we can may several hypothesis:
   a) a1.f->PHI   b1.f->PHI  b1.f'->PHI'  -- a possible interpretation of p261
   b) a1.f->PHI'  b1.f->PHI  b1.f'->PHI'  -- another ...
   c) a1.f->PHI'  b1.f->PHI' b1.f'->PHI'' -- current implementations
   d) a1.f->PHI'' b1.f->PHI' b1.f'->PHI'' -- the table

The hypothesis a) is already provided by the case #1:
   class B export f, f'
   inherit A
   feature 
       f' is do PHI' end
   end -- B
Remark: the term "illegal" in the table is abusive: we can give new definitions
for f or f' when they are not defined by the inheritance.

The hypothesis c) (current implementation of #6) is also provided by the
case #3
    class B export f, f'
    inherit A redefine f
    feature
        f  is do PHI'  end; -- redefinition
        f' is do PHI'' end; -- new definition
    end -- B
So, the current implementation is certainly erroneous.

The last two hypothesis b) and d) (we shall discuss their utility below) are
the only they have
             (a1.f alias b1.f') and (a1.f /= b1.f).
They can't be provided by the other cases, consequently are possibly useful.

The case #6 is written in Eiffel:
    class B export f, f'
    inherit A
        rename f as f'    -- here f' refers to PHI
        redefine f, f'    -- the reference to PHI is lost
    feature
       f  is do PHI'  end;
       f' is do PHI'' end;
    end

Thus, the syntax suggests only the hypothesis d) as possible; Moreover, the
case b), can be obtained by the case d) with a client use to refer PHI:
    class B export f, f'
    inherit A
        rename f as f'    -- here f' refers to PHI
        redefine f, f'    -- the reference to PHI is lost
    feature
       a: A;
       Create is do a.Create end;
       f      is do a.f      end; -- PHI
       f'     is do PHI'     end;
    end

Consequently, I believe:
  - the table page 260 of The book is correct,
  - the current implementation is erroneous,
  - the explanation p 261 about case #6 is not clear.

In my opinion, the case #6 is useful for the rare cases (currently not used in
standard library, maybe that explains the bug wasn't found), where we need
a1.f (the view from a) differs b1.f (the view from b), e.g. for
performance considerations. The fact "b1.f' is an alias of a1.f" is useful
to get access, in B, to the implementation of the view from A (not original
version PHI, as mentioned p 261).

Can Bertrand confirm or contest all that?

2. Suggestions to understand this table
---------------------------------------

In my opinion, the main reason of difficulties to understand this table come
from the fact, the actions in the second column are not in the rigth order,
as in the Eiffel syntax. Luckely, this table isn't essential to understand
or write Eiffel programs: it's sufficient to follow the syntax.

Example, case #4:

class B export f, f'
inherit
    A
        rename f as f' -- here, b1.f' refers to PHI - f isn't more defined ...
        redefine f     -- but there is a  redefinition,
                       -- therefore the implementation of the view of A a1.f,
                       -- is changed; by what? the only possibility is PHI'.
    feature         
         f is do PHI' end; -- b1.f refers to PHI', what others else?
end -- B

Example, case #5:

class B export f, f'
inherit
    A
        rename f as f' -- here, b1.f' refers to PHI - f isn't more defined ...
        redefine f'    -- but there is a redefinition,
                       -- therefore, the implementation of the view of A a1.f,
                       -- is changed; by what? the only possibility PHI''.
                       -- f is not redefined, therefore b1.f either is illegal
                       -- or refers to a new definition.
    feature         
         f' is do PHI'' end; -- b1.f' refers to PHI'', as it's logical.
end -- B

The case #6 is more difficult, but very rare; we only have to remember that
f' prevails over f.

Be indulgent to my english!

======
Roger Rousseau          ESSI                         LISAN
rr@cerisi.cerisi.fr     Universite' de Nice          CNRS / bat 3
rr@mirsa.inria.fr       Dept. d'informatique         Rue Albert Einstein
                        Parc Valrose                 Sophia Antipolis
                        06034 Nice cedex - France    06560 Valbonne - France


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