On 05/05/2012 15:07, deadalnix wrote:
<snip>
http://se.ethz.ch/~meyer/publications/computer/contract.pdf
The extract of the book covering that specific point is available
here. Meyer explain HOW thing work and then how this behavior
provide some benefices. Careful reading of the passage show that
BOTH behavior we are talking here provide such benefices. This
reading isn't going to conclude the discussion.
Exactly. Moreover, I noticed that you quoted portions of it on BZ, including
"Yet, because of dynamic binding, A may subcontract the execution of r to B, and it is B’s
contract that will be applied."
There seems to be an unfounded assumption here: that a compiler will necessarily implement
contract checking as part of the method body. Really, there's no explanation of "it is
B’s contract that will be applied" there. Contract checking happens before and is
conceptually separate from method execution.
Additionally, Meyer state that the in contract is a constraint for
the caller. This is an argument in favor of view (a).
That is indeed what it seems to be saying. Among other things:
"A precondition violation indicates a bug in the client (caller). The caller did not
observe the conditions imposed on correct calls."
<snip>
The fizzbuzz function here is flawed. bar doesn't provide any
guarantee on its return value. foo expect fizzbuzz to provide a
parameter with certain properties.
Taken the words out of my mouth there. fizzbuzz is not using the class B. It is using
the class A. Going by view (a), since foo(-1) is not a legal call according to A's API -
and moreover, A's API makes no guarantees that foo(bar()) generally will be a legal call -
the code is incorrect.
I agree with the rest of your points as well.
<snip>
Maybe what's needed is a clarification in the spec of which
concept of an in contract (view (a), view (b) or something else) D
intends to implement.
The spec is very explicit on that point. view (b) is the specified
one. But I think it is an error.
<snip>
Where is it addressed?
Stewart.
