From f17b03beee31327d3f23adc8d6d070e967a2a364 Mon Sep 17 00:00:00 2001 From: halw Date: Sat, 31 Mar 2012 18:29:59 +0000 Subject: [PATCH] Clarification in wording of postcondition caveat. Author:halw Date:2012-03-31T18:29:59.000000Z git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1057 abb3cda0-5349-4a8f-a601-0c33ac3a8c38 --- .../concurrent-computing/concurrent-eiffel-scoop/index.wiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki index 5c68a25c..207d74bc 100644 --- a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki +++ b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki @@ -253,7 +253,7 @@ So, the client's responsibility is limited to those precondition clauses that ar As with preconditions the effect of concurrent execution can make a difference in how postconditions are viewed. -If a routine has executed correctly, then the postcondition of the routine will hold at the time that it terminates ... this is true whether or not concurrency is involved. However, when a postcondition involves separate calls or entities are involved, clients must be cautious about how they depend upon the state guaranteed by postconditions. +If a routine has executed correctly, then the postcondition of the routine will hold at the time that it terminates ... this is true whether or not concurrency is involved. However, when a postcondition involves separate calls or entities, clients must be cautious about how they depend upon the state guaranteed by postconditions. ===Class invariants===