http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #47 from Walter Bright <bugzi...@digitalmars.com> 2012-05-05 02:02:48 PDT --- (In reply to comment #46) > Now, change F from a struct to a class. We believe that the code should still > fail to compile. A theorem prover could not produce a compile time error, because it could not prove that f is actually an F, and not of a class derived from F. OOP is runtime polymorphism, not compile time. A struct type is fundamentally different from a class type. And lastly, your request is quite different from Example #1, which is asserting that the contract for A.foo() must always pass, even if it's calling B.foo(). I know I sound like a broken record, but please read Meyer's book. He shows how the behavior of contracts is a derived consequence from OOP principles. It is not a separate invention with separate rules. Hence it is not a matter of belief - it is a matter of proof. --- Comment #48 from Walter Bright <bugzi...@digitalmars.com> 2012-05-05 02:03:05 PDT --- (In reply to comment #46) > Now, change F from a struct to a class. We believe that the code should still > fail to compile. A theorem prover could not produce a compile time error, because it could not prove that f is actually an F, and not of a class derived from F. OOP is runtime polymorphism, not compile time. A struct type is fundamentally different from a class type. And lastly, your request is quite different from Example #1, which is asserting that the contract for A.foo() must always pass, even if it's calling B.foo(). I know I sound like a broken record, but please read Meyer's book. He shows how the behavior of contracts is a derived consequence from OOP principles. It is not a separate invention with separate rules. Hence it is not a matter of belief - it is a matter of proof. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------