[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 #51 from deadalnix <deadalnix at 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: -------