From: jcm@hgc.edu (James McKim)
Subject: Re: Conformance
Organization: The Hartford Graduate Center
Date: Fri, 14 Aug 1992 15:09:55 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 :-)

Sorry about that. All the smart Eiffel users take August off, which leaves
me to respond. I had to recast your example into Eiffel 2.3 syntax
so I could check it out. I think my conclusion is valid for Eiffel 3 as well.
>
>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 :-)

Yikes! Who's second against the wall?

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

One nitpick. You can't redefine grade (or any attribute) to be a
constant. At least not in v2.3. 
 
>
>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 is what needs redefining to solve the problem. In particular
redefine infix "<" in EMPLOYEE as

    infix "<" (other : EMPLOYEE) : BOOLEAN is ....

You will also have to redefine the other relational operators similarly
if you want to use them 
>
>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)?
>I'm afraid I don't have a compiler to check this out.  If this is indeed the

You are correct that *2* will not compile. The only way I see to
fix it is to redefine infix "<" in EMPLOYEE as

    infix "<" (other : EMPLOYEE) : BOOLEAN is ....

You will also have to redefine the other relational operators similarly
if you want to use them to compare descendants of EMPLOYEE with
each other.


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

COMPARABLE is too abstract a class to be used as the basis for sorting.
If I have one descendant that implements "<" via an integer comparison
and another that implements "<" via a string comparison, how could
I ever reasonably compare an object of the first type with an object of
the second?

On the other hand SORTED_LIST[T->EMPLOYEE] is perfectly reasonable
given the definition of "<" above.

>
>
>Matthew
>--
>---* Amnesiac the Wizard *------------------* matthew@uk.tele.nokia.fi *---
> Opinions expressed here are not those of my company.    | NB. ntl02 is EN
> They're not even my own; I plagiarised the lot of them! | TEE EL ZERO TWO
>---* matthew@ntl02.decnet.nokia.fi *------------------* Matthew Faupel *---


Hope this helps
-- Jim
-- 

*------------------------------------------------------------------------------*
Jim McKim  (203)-548-2458     In exactly 3.2 seconds it will be a few 
Internet:  jcm@hgc.edu   minutes to 5:00.