home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / eiffel / 1442 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  2.3 KB
  1. Path: sparky!uunet!cs.utexas.edu!usc!news.service.uci.edu!network.ucsd.edu!lyapunov.ucsd.edu!mbk
  2. From: mbk@lyapunov.ucsd.edu (Matt Kennel)
  3. Newsgroups: comp.lang.eiffel
  4. Subject: Re: creation
  5. Date: 20 Jan 1993 21:33:08 GMT
  6. Organization: Institute For Nonlinear Science, UCSD
  7. Lines: 43
  8. Message-ID: <1jkgekINNa4i@network.ucsd.edu>
  9. References: <175@eiffel.eiffel.com>
  10. NNTP-Posting-Host: lyapunov.ucsd.edu
  11. X-Newsreader: Tin 1.1 PL3
  12.  
  13. ram@eiffel.com (Raphael Manfredi) writes:
  14. : I think there are some situations where a creation procedure may require a
  15. : postcondition, completing the assertions coming from the invariant. For
  16. : instance, assume you are creating an object representing a Finite State
  17. : Automaton (FSA). You may want to have two or three creation procedures
  18. : to make sure the FSA is put in one of its "begining" states. The postcondition
  19. : would express that the FSA is indeed in the correct state.
  20.  
  21. I have a basic question here.
  22.  
  23. How are postconditions useful?  It seems that they express little
  24. beyond the correct functioning of a class feature.
  25.  
  26. : Note that aside from the fact '!!' involves a run-time call to create the
  27. : object, it also has a semantic meaning: it tells the compiler NOT to check the
  28. : invariant when calling 'o.make' on the newly allocated object. Usually, the
  29. : invariant is checked BEFORE and AFTER a remote call (see OOSC for a detailed
  30. : explaination).
  31.  
  32. It seems then that you could always write some sort of invariant as
  33. either (object_is_not_initialized) or (regular_conditions).
  34.  
  35. Also it seems that frequently data structures have "lifecycles", i.e.
  36. initialization, normal_use, and destruction, and that an invariant that
  37. is supposed to be true during normal use doesn't necessarily have to be
  38. so during initialization.
  39.  
  40. In what way can invariants express relationships between different objects.
  41. That's where the most non-trivial problems seem to come into play.
  42.  
  43. cheers
  44. Matt
  45. : -- 
  46. : Raphael Manfredi <ram@eiffel.com>
  47. : Interactive Software Engineering Inc.
  48. : 270 Storke Road, Suite #7                      / Tel +1 (805) 685-1006 \
  49. : Goleta, California 93117, USA                  \ Fax +1 (805) 685-6869 /
  50.  
  51. --
  52. -Matt Kennel          mbk@inls1.ucsd.edu
  53. -Institute for Nonlinear Science, University of California, San Diego
  54. -*** AD: Archive for nonlinear dynamics papers & programs: FTP to
  55. -***     lyapunov.ucsd.edu, username "anonymous".
  56.