http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #51 from deadalnix <deadal...@gmail.com> 2012-05-05 06:22:21 PDT --- (In reply to comment #49) > Runtime polymorphism is about overriding behaviour, not overriding legality. > This is, indeed, the whole essence of the problem. (In reply to comment #48) > 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'm afraid this explains why we are not getting anywhere in this discussion. The whole proposal is, and have always been that one. Read again example code I've posted and which check is performed in which case. I have read Mayer's document about contract and OOP, and I want to comment here the explanations given by Meyer himself. Quoted passage are from the book. Mayer have a very similar example to the one I gave above. You have classes A and B inheriting from A. A define a method r with an in contract, that B override. A variable u of type A is used in method X. You can map as this : r <=> foo, u <=> a and X <=> fizzbuzzA « To ascertain the properties of the call u.r, the author of X can only look at the contract for r in A. Yet, because of dynamic binding, A may subcontract the execution of r to B, and it is B’s contract that will be applied. » Here, Meyer is stating HOW thing work before it explain WHY. Hence, the whole stuff is to show how this specific implementation satisfy certain properties. Let see what are these properties and what is the situation with the new proposed behavior. « How do you avoid “fooling” X in the process? There are two ways B could violate its prime contractor’s promises: - B could make the precondition stronger, raising the risk that some calls that are correct from x’s viewpoint (they satisfy the original client obligations) will not be handled properly. » I omitted the second one as it is about out contract so off topic here. the constraint expressed here is respected by both current solution, and proposed solution. « None of this, then, is permitted. But the reverse changes are of course legitimate. A redeclaration may weaken the original’s precondition or it may strengthen the postcondition. » Again, both proposals allow this. « Redeclaration. for all the power it brings to software development. is not a way to turn a routine into something completely different. The new version must remain compatible with the original specification. although it may improve on it. The noted rules express this precisely. » Meyer is right. His rules express this. But proposed rules express this too. He then conclude « In this way. the new precondition is guaranteed to be weaker than or equal to the originals, and the new postcondition is guaranteed to be stronger than or equal to the originals. » Again according to Meyer's argumentation, both behavior are corrects. It appears (and I have read the chapter several times to make sure I'm not missing something) that Meyer's doesn't provide any argument about our special case here. I'm sorry, but this reading can't close the discussion. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------