home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / eiffel / 1065 < prev    next >
Encoding:
Text File  |  1992-08-14  |  4.0 KB  |  111 lines
  1. Newsgroups: comp.lang.eiffel
  2. Path: sparky!uunet!psinntp!merlin.hgc.edu!jcm
  3. From: jcm@hgc.edu (James McKim)
  4. Subject: Re: Conformance
  5. Message-ID: <1992Aug14.150955.10604@merlin.hgc.edu>
  6. Sender: usenet@merlin.hgc.edu (Action News Central)
  7. Organization: The Hartford Graduate Center
  8. References: <MATTHEW.92Aug12100841@matthew.ntl02.decnet.nokia.fi>
  9. Date: Fri, 14 Aug 1992 15:09:55 GMT
  10. Lines: 99
  11.  
  12. In article <MATTHEW.92Aug12100841@matthew.ntl02.decnet.nokia.fi> matthew@ntl02.decnet.nokia.fi (Matthew Faupel) writes:
  13. >Nobody answered this the first time round, so I'll try again.  There must be
  14. >at least one *real* Eiffel user who reads this conference and can answer the
  15. >question (as opposed to all us kibbitzers :-)
  16.  
  17. Sorry about that. All the smart Eiffel users take August off, which leaves
  18. me to respond. I had to recast your example into Eiffel 2.3 syntax
  19. so I could check it out. I think my conclusion is valid for Eiffel 3 as well.
  20. >
  21. >Here it is again:
  22. >
  23. >2.  A question about conformance and the like.  Here's an attempt to create
  24. >a hierarchy of classes representing employees which have a distinguishing
  25. >attribute "grade" on which they can be sorted (so we know who's first
  26. >against the wall when the revolution comes :-)
  27.  
  28. Yikes! Who's second against the wall?
  29.  
  30. >
  31. >class EMPLOYEE inherit                       class MANAGER inherit
  32. >   INT_COMPAR                                   EMPLOYEE
  33. >      rename   item as grade                       redefine grade
  34. >      redefine grade                            end
  35. >   end
  36. >                                                feature
  37. >   feature                                         grade: INTEGER is 2
  38. >      grade: INTEGER is 1                    end
  39. >end
  40.  
  41. One nitpick. You can't redefine grade (or any attribute) to be a
  42. constant. At least not in v2.3. 
  43.  
  44. >
  45. >somewhere else...
  46. >
  47. >   fred: EMPLOYEE;
  48. >   bill: MANAGER;
  49. >
  50. >   !!fred; !!bill;
  51. >   if fred < bill then ...           -- *1*
  52. >   if bill < fred then ...           -- *2*
  53. >
  54. >as a reminder, the declaration of infix "<" in class INT_COMPAR is:
  55. >   infix "<" (other: like Current): BOOLEAN
  56.  
  57. This is what needs redefining to solve the problem. In particular
  58. redefine infix "<" in EMPLOYEE as
  59.  
  60.     infix "<" (other : EMPLOYEE) : BOOLEAN is ....
  61.  
  62. You will also have to redefine the other relational operators similarly
  63. if you want to use them 
  64. >
  65. >This leads me to ask, in the above example does *1* compile OK (as bill
  66. >conforms to EMPLOYEE) but *2* not (as fred does not conform to MANAGER)?
  67. >I'm afraid I don't have a compiler to check this out.  If this is indeed the
  68.  
  69. You are correct that *2* will not compile. The only way I see to
  70. fix it is to redefine infix "<" in EMPLOYEE as
  71.  
  72.     infix "<" (other : EMPLOYEE) : BOOLEAN is ....
  73.  
  74. You will also have to redefine the other relational operators similarly
  75. if you want to use them to compare descendants of EMPLOYEE with
  76. each other.
  77.  
  78.  
  79. >case, how in general should you implement this type of thing, e.g. a class
  80. >  SORTED_LIST[T->COMPARABLE]
  81. >where in fact the members of the list are hetrogeneous objects that conform
  82. >to COMPARABLE, but not necessarily to each other?  If it isn't the case,
  83. >what have I misunderstood?
  84.  
  85. COMPARABLE is too abstract a class to be used as the basis for sorting.
  86. If I have one descendant that implements "<" via an integer comparison
  87. and another that implements "<" via a string comparison, how could
  88. I ever reasonably compare an object of the first type with an object of
  89. the second?
  90.  
  91. On the other hand SORTED_LIST[T->EMPLOYEE] is perfectly reasonable
  92. given the definition of "<" above.
  93.  
  94. >
  95. >
  96. >Matthew
  97. >--
  98. >---* Amnesiac the Wizard *------------------* matthew@uk.tele.nokia.fi *---
  99. > Opinions expressed here are not those of my company.    | NB. ntl02 is EN
  100. > They're not even my own; I plagiarised the lot of them! | TEE EL ZERO TWO
  101. >---* matthew@ntl02.decnet.nokia.fi *------------------* Matthew Faupel *---
  102.  
  103.  
  104. Hope this helps
  105. -- Jim
  106. -- 
  107.  
  108. *------------------------------------------------------------------------------*
  109. Jim McKim  (203)-548-2458     In exactly 3.2 seconds it will be a few 
  110. Internet:  jcm@hgc.edu   minutes to 5:00.
  111.