From: richieb@bony1.bony.com (Richard Bielak)
Subject: Re: Conformance
Organization: multi-cellular
Date: Fri, 14 Aug 92 02:51:39 GMT

In article <MATTHEW.92Aug12100841@matthew.ntl02.decnet.nokia.fi> matthew@ntl02.decnet.nokia.fi (Matthew Faupel) writes:
>Nobody answered this the first time round, so I'll try again.  There must be
>at least one *real* Eiffel user who reads this conference and can answer the
>question (as opposed to all us kibbitzers :-)
>

Well, I'm a *real* Eiffel user, although, I'm still using Eiffel 2.3.
I'll try to answer your question.

>Here it is again:
>
>2.  A question about conformance and the like.  Here's an attempt to create
>a hierarchy of classes representing employees which have a distinguishing
>attribute "grade" on which they can be sorted (so we know who's first
>against the wall when the revolution comes :-)
>
>class EMPLOYEE inherit                       class MANAGER inherit
>   INT_COMPAR                                   EMPLOYEE
>      rename   item as grade                       redefine grade
>      redefine grade                            end
>   end
>                                                feature
>   feature                                         grade: INTEGER is 2
>      grade: INTEGER is 1                    end
>end
>
>somewhere else...
>
>   fred: EMPLOYEE;
>   bill: MANAGER;
>
>   !!fred; !!bill;
>   if fred < bill then ...           -- *1*
>   if bill < fred then ...           -- *2*
>
>as a reminder, the declaration of infix "<" in class INT_COMPAR is:
>   infix "<" (other: like Current): BOOLEAN
>
>This leads me to ask, in the above example does *1* compile OK (as bill
>conforms to EMPLOYEE) but *2* not (as fred does not conform to
MANAGER)?

You are correct *2* will not compile, as EMPLOYEE does not conform
to MANAGER (hey, I like the sound of this :-)).

>I'm afraid I don't have a compiler to check this out.  If this is indeed the
>case, how in general should you implement this type of thing, e.g. a class
>  SORTED_LIST[T->COMPARABLE]
>where in fact the members of the list are hetrogeneous objects that conform
>to COMPARABLE, but not necessarily to each other?  If it isn't the case,
>what have I misunderstood?
>

There is no problem in implementing SORTED_LIST [EMPLOYEE]. Now you
can put anything in the list that conforms to EMPLOYEE. Since MANAGER
inherits from EMPLOYEE, it can be added to the list, as the routine
that adds elements is declared as:

     put (new_item : EMPLOYEE);

As far as the comparisons within the SORTED_LIST code, everything here
is declared of static type EMPLOYEE (actually "T", which is replaced
by "EMPLOYEE" to be more precise). So within SORTED_LIST only things
declared as EMPLOYEE are compared.

However, to a variable of type EMPLOYEE you can attach a reference
of an object that conforms to EMPLOYEE, eg. object of type MANAGER.
From then on, dynamic binding takes care of invocation of the correct
"grade" to perform comparisons.


I hope this answers your question. 

...richie

P.S. I didn't respond sooner, since I'm on vacation :-).

P.P.S. You cannot redefine an atttribute to be a constant. 


-- 
* Richie Bielak   (212)-815-3072   | "Your brain is a liquid-cooled parallel  *
* Internet:       richieb@bony.com | super-computer". He pointed to his nose, *
* Bang {uupsi,uunet}!bony1!richieb | "This is the fan."                       *
*    - Strictly my opinions -      |                     - David Chudnovsky - *
Newsgroups: comp.lang.eiffel