home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.eiffel
- Path: sparky!uunet!psinntp!bony1!richieb
- From: richieb@bony1.bony.com (Richard Bielak)
- Subject: Re: Conformance
- Message-ID: <1992Aug14.025139.13055@bony1.bony.com>
- Organization: multi-cellular
- References: <MATTHEW.92Aug12100841@matthew.ntl02.decnet.nokia.fi>
- Date: Fri, 14 Aug 92 02:51:39 GMT
- Lines: 85
-
- 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 - *
-