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

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sat May 5 05:02:54 PDT 2012


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



--- Comment #50 from deadalnix <deadalnix at gmail.com> 2012-05-05 05:04:07 PDT ---
(In reply to comment #33)
> (In reply to comment #32)
> > (In reply to comment #30)
> > > fizzbuzz() clearly has a bug. It will fail if given an A which isn't actually a
> > > B.
> > 
> > Exactly.  fizzbuzz is calling a method of A, not a method of B.  As such, as
> > I've already said, it must conform to A's API, but it is failing to do so.
> 
> First off, if fizzbuzz() is passed an A, then it will (correctly) fail. Where's
> the bug in the contract design? Secondly, the -1 may not be a literal, it may
> be a value computed from B, as in:
> 
> 
>  class A {
>      void foo(int x) in { assert(x > 0); } body {}
>      int bar() { return 1; }
>  }
> 
>  class B : A {
>      void foo(int x) in { assert(x > -2); } body {}
>      int bar() { return -1; }
>  }
> 
>  void fizzbuzz(A a) {
>      a.foo(bar());
>  }
> 
> So, clearly is NOT required that a.foo(arg) pass A.foo's contract.
> 
> The design of OOP and contracts is sound. Correct programs will pass, and
> incorrect programs will fail. I don't see any "corner cases" otherwise.

This piece of code is good for an horror museum.

If bar is a valid argument for foo, then A should have the following definition
:

class A {
    void foo(int x) in { assert(x > 0); } body {}
    int bar() out(result) { assert( result > 0); } body { return 1; }
}

And, with such a definition, out contract would prevent B.bar to return -1 .

BTW, I found this PDF on Meyer's website :
se.ethz.ch/~meyer/publications/computer/contract.pdf . It seems that he decided
to publish the part of the book that is relevant to us online. I'm reading it
right now.

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


More information about the Digitalmars-d-bugs mailing list