Static versus dynamic binding of in contracts again - trying to set things straight

[Stewart Gordon]

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.