home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / object / 4607 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.8 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!zaphod.mps.ohio-state.edu!sdd.hp.com!ux1.cso.uiuc.edu!cs.uiuc.edu!johnson
  2. From: johnson@cs.uiuc.edu (Ralph Johnson)
  3. Newsgroups: comp.object
  4. Subject: Re: Object hidden state and side effects
  5. Message-ID: <BzKv4J.3Lt@cs.uiuc.edu>
  6. Date: 20 Dec 92 21:45:54 GMT
  7. References: <1992Dec16.65250.10645@kei.is.s.u-tokyo.ac.jp> <1992Dec16.175126.14968@midway.uchicago.edu> <BzIFGp.K7@cs.uiuc.edu> <1992Dec20.155809.14236@midway.uchicago.edu>
  8. Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
  9. Lines: 48
  10.  
  11. dave@alex.uchicago.edu (Dave Griffith) writes:
  12.  
  13. >>>But most languages have no way to _enforce_ the requirement that they "only
  14. >>>allow operations that are in line with their essential sameness".  
  15.  
  16. I then argued that most languages have no way of enforcing most interesting
  17. things.  In particular, I said:
  18.  
  19. >>We can't really enforce that a subclass provides the same behavior
  20. >>as a superclass.
  21.  
  22. Dave Griffith replied:
  23.  
  24. >Eiffel (with the exclusion of a few egregious features like
  25. >"undefine") can and does enforce that a subclass has the same behavior as
  26. >a superclass.
  27.  
  28. This is a common misconception.  I'm a fan of Eiffel, and I applaud the
  29. attempt to put more design information in programs by using assertions and
  30. invariants, but there is still a lot of interesting behavior (in fact,
  31. most interesting behavior) that can't be specified.  Reusing an earlier
  32. example, try specifying that equality is symmetric, reflexive, transitive, 
  33. and substitutabilty of equals for equals should hold in all cases. I think
  34. that symmetry should be easy to specify.  Reflexivity and transitivity
  35. are usually easy to prove, but I don't think you can express them in Eiffel,
  36. since it doesn't have a "for all" construct.  Probably you can enforce
  37. reflexivity by stating that an object is equal with itself whenever you
  38. create a new object.  I don't have any idea about transitivity, nor about
  39. substitutability of equals for equals.
  40.  
  41. If it turns out that there is a way to express that in Eiffel, how about
  42. my example of requiring that a function used by a sorter provide
  43. a total ordering on the collection to be sorted.  I guess you could
  44. do this for any particular finite collection by checking all triples.
  45. However, I don't think Eiffel allows loops in assertions.
  46.  
  47. It is not hard to make an assertion language that is more
  48. powerful than the one in Eiffel.  However, it would then
  49. become much more expensive to check.
  50.  
  51. Getting back to objects vs. values, I agree that reasoning about 
  52. side effects is important.  Promising approaches are Gifford's
  53. "effects" system that was described in a POPL'88 (and other places
  54. that I forget) and Hogg's "Islands" that was described in OOPSLA '91.
  55. I'm just not convinced that making a hard and fast distinction 
  56. between objects and values is necessarily a good idea.
  57.  
  58. -Ralph Johnson
  59.