home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / eiffel / 1376 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  1.9 KB
  1. Path: sparky!uunet!eiffel!eiffel.com
  2. From: ram@eiffel.com (Raphael Manfredi)
  3. Newsgroups: comp.lang.eiffel
  4. Subject: Re: Semantics of invariants
  5. Message-ID: <159@eiffel.eiffel.com>
  6. Date: 16 Dec 92 18:13:29 GMT
  7. References: <1992Dec15.213603.16406@bony1.bony.com> <1992Dec16.163847.17559@nrao.edu>
  8. Sender: ram@eiffel.com
  9. Organization: Interactive Software Engineering, Santa Barbara CA
  10. Lines: 35
  11.  
  12. Quoting cflatter@nrao.edu from comp.lang.eiffel:
  13. >In article 16406@bony1.bony.com, richieb@bony1.bony.com (Richard Bielak) writes:
  14. >>Is the invariant supposed to be true *ALL* the time, once the object is
  15. >>created? 
  16. >>
  17. >You can invalidate a class invariant inside a function or procedure
  18. >provided that it is true on exit.  In other words the class invariant
  19. >is an implicit conjunct of both the precondition and the postcondition
  20. >of a function or procedure.
  21.  
  22. Well, that's not completely true. The invariant is indeed added to the
  23. preconditions and postconditions of a feature ONLY when called remotely,
  24. i.e. when you write:
  25.  
  26.     a.f;
  27.  
  28. If you only call:
  29.  
  30.     f;
  31.  
  32. then the invariant is NOT checked. The reason behind this is that one class
  33. (e.g. SORTED_TWO_WAY_LIST) may temporarily violate its invariant (typically
  34. when sorting the list). The sorting algorithm may well rely on two or three
  35. subroutines, and checking the invariant while in an inconsistent state would
  36. be fatal... At the time the execution flow "exits" from the class (i.e. when
  37. we return from the feature in SORTED_TWO_WAY_LIST which was called by a client),
  38. then of course the invariant must be checked.
  39.  
  40. This makes the "invariant check" operation difficult, if not impossible, to
  41. implement concurrently as Richard Bielak suggested it.
  42. -- 
  43. Raphael Manfredi <ram@eiffel.com>
  44. Interactive Software Engineering Inc.
  45. 270 Storke Road, Suite #7                      / Tel +1 (805) 685-1006 \
  46. Goleta, California 93117, USA                  \ Fax +1 (805) 685-6869 /
  47.