http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #50 from deadalnix <deadal...@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: -------