home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / object / 3041 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  2.7 KB
  1. Xref: sparky comp.object:3041 comp.lang.eiffel:1004
  2. Newsgroups: comp.object,comp.lang.eiffel
  3. Path: sparky!uunet!mcsun!sunic!psinntp!psinntp!merlin.hgc.edu!jcm
  4. From: jcm@hgc.edu (James McKim)
  5. Subject: Re: Class methods (was: Re: How to design a data structure library)
  6. Message-ID: <1992Jul28.135521.28003@merlin.hgc.edu>
  7. Sender: usenet@merlin.hgc.edu (Action News Central)
  8. Organization: The Hartford Graduate Center
  9. References: <GEOFF.92Jul27100601@wodehouse.flash.bellcore.com> <5631@vexpert.dbai.tuwien.ac.at>
  10. Date: Tue, 28 Jul 1992 13:55:21 GMT
  11. Lines: 51
  12.  
  13. In article <5631@vexpert.dbai.tuwien.ac.at> mst@vexpert.dbai.tuwien.ac.at (Markus Stumptner) writes:
  14. >From article <GEOFF.92Jul27100601@wodehouse.flash.bellcore.com>, by geoff@flash.bellcore.com (Geoffrey Clemm):
  15. >> I believe you missed the central point of Richie's article, namely that
  16. >> Eiffel 3.0 has a clean way of handling this situation, to quote:
  17. >
  18. >>>     !!c.union (a,b);
  19. >
  20. >> With which I completely agree.  This avoids the unpleasant assymetry
  21. >> of c:=a.union(b).
  22. >
  23. >I did get the point, I just don't like it.  I grant that the asymmetry
  24. >is avoided, but this is outwiehged by the fact that using the class
  25. >method is, in my opinion, a completely weird way of handling an
  26. >ordinary binary operator.  Sets are a bad example for that construct,
  27. >since they, as mathematical entities together with their appropriate
  28. >operators, should correspond fairly closely to, say, integers or
  29. >floats in this manner.  As an example, addition (which closely
  30. >corresponds to set union) is not a class message, and making it one
  31. >does not improve the clarity of the code.
  32. >
  33.  
  34. [...]
  35.  
  36. But, addition (set union) can be viewed as a way of combining two
  37. integers (sets) to form a _new_ one. The very fact that the result is
  38. _new_ indicates some form of creation. 
  39.  
  40. What I think we're leading up to here is a distinction between two 
  41. kinds of queries:
  42.    1) Those that _clearly_ return some new object: union of two
  43.      sets, concatenation of two lists, etc.
  44.  
  45.    2) Those that don't: top of a stack, length of a list, etc.
  46.  
  47.  
  48. In order to qualify under (1) the result of the query must be 
  49. heavily dependent on the parameters of the query. If the result 
  50. only depends on the state of the object, then the design of the
  51. class should allow the implementor the flexibility of precomputing
  52. and storing the result of the query in anticipation of future access. 
  53. For example the length of a list can be constantly maintained or
  54. computed on demand and so falls under (2). (Meyer has a name for 
  55. this kind of transparency which escapes me at the moment.) 
  56.  
  57. Regards,
  58. -- Jim
  59. -- 
  60.  
  61. *------------------------------------------------------------------------------*
  62. Jim McKim  (203)-548-2458     In exactly 3.2 seconds it will be a few 
  63. Internet:  jcm@hgc.edu   minutes to 5:00.
  64.