home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / eiffel / 1380 < prev    next >
Encoding:
Text File  |  1992-12-17  |  2.2 KB  |  56 lines
  1. Newsgroups: comp.lang.eiffel
  2. Path: sparky!uunet!mcsun!news.funet.fi!network.jyu.fi!sakkinen
  3. From: sakkinen@jyu.fi (Markku Sakkinen)
  4. Subject: Re: Semantics of invariants
  5. Message-ID: <1992Dec17.153736.19608@jyu.fi>
  6. Organization: University of Jyvaskyla, Finland
  7. References: <1992Dec15.213603.16406@bony1.bony.com> <1992Dec16.163847.17559@nrao.edu> <159@eiffel.eiffel.com>
  8. Date: Thu, 17 Dec 1992 15:37:36 GMT
  9. Lines: 45
  10.  
  11. In article <159@eiffel.eiffel.com> ram@eiffel.com (Raphael Manfredi) writes:
  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. > ...
  35.  
  36. Right.  This suggests the need for a declaration that certain routines
  37. should _not_ be callable from the Current object itself (except from
  38. read-only routines), since they may be written assuming that the invariant
  39. holds.
  40.  
  41. There is an additional complication:  a remote call may cause other
  42. remote calls back to the calling object before returning.
  43. I.e. the same object may appear more than once on the execution stack
  44. even in a purely sequential system.  This is no Eiffel-specific problem.
  45. (Richard Bielak may have had it also in mind in his original question.)
  46.  
  47. ----------------------------------------------------------------------
  48. Markku Sakkinen (sakkinen@jytko.jyu.fi)
  49.        SAKKINEN@FINJYU.bitnet (alternative network address)
  50. Department of Computer Science and Information Systems
  51. University of Jyvaskyla (a's with umlauts)
  52. PL 35
  53. SF-40351 Jyvaskyla (umlauts again)
  54. Finland
  55. ----------------------------------------------------------------------
  56.