[Issue 6857] Precondition contract checks should be statically bound.

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #30 from Don <clugdbug at yahoo.com.au> 2012-05-04 05:57:39 PDT ---
(In reply to comment #29)
> (In reply to comment #28)
> > > The literally FIRST hit takes to a slide deck, see http://goo.gl/544fU. There
> > > there is theory and examples on how contracts work. 
> > 
> > Andrei, those slides don't address the issue at all.
> 
> The issue as exemplified herein is:
> 
> class A {
>     void foo(int x) in { assert(x > 0); } body {}
> }
> 
> class B : A {
>     void foo(int x) in { assert(x > -2); } body {}
> }
> 
> void fizzbuzz(A a) {
>     a.foo(-1);
> }
> 
> The question is, why does the code work when A's contract is in fact violated.
> Slide 22-10 in that deck gives as example a method invert(). The base class has
> precondition epsilon >= 10^(– 6) and the derived class has precondition epsilon
> >= 10^(– 20). The surrounding slides explain rather copiously how a call to
> invert against the derived class works even though the precondition of the base
> class is violated (e.g. by passing epsilon = 10^(– 10). The example given in
> the slides has a straightforward correspondence to the one above.

You are making a massive assumption here, which I don't see in the slides. The
assumption is that fizzbuzz gets access to B's weakened precondition.
I've looked all over the Eiffel website and haven't seen anything which implies
that. Rather, everything I read implies that it's a contract -- it's the
clients responsibility to ensure that the precondition is satisfied. fizzbuzz
doesn't have a contract with B, it doesn't even know that B exists.

fizzbuzz() clearly has a bug. It will fail if given an A which isn't actually a
B.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------