On 1/19/2012 4:08 PM, Jonathan M Davis wrote:
On Thursday, January 19, 2012 17:29:28 bearophile wrote:
If I am mistaken please I'd like to know why the current design is better
(or maybe why it's just equally good). Thank you :-)
Honestly, I don't think that the order is all that critical, since all of the
same assertions are run in either case. But conceptually, the invariant is for
verifying the state of the object, whereas the post-condition is for verifying
the state of the return value. And the return value doesn't really matter if
the object itself just got fried by the function call. Not to mention, if your
tests of the return value in the post-condition rely on the state of the
object itself being correct, then your tests in the post-condition aren't
necessarily going to do what you expect if the invariant would have failed.
I have no idea what Walter's reasoning is though.
- Jonathan M Davis
I certainly can't speak for Walter, either, but to my mind, the
precondition/invariant/body/invariant/postcondition order makes sense,
because the object's internal monologue goes like
precondition: "Does this guy even have any business calling me?"
(does he meet my method's preconditions?"
invariant: "Am I in any shape to do the job for him?"
(do I meet my class invariant, am I a "real" X object?)
body: Yo.
invariant: "Am I still in good shape?"
(did I break something, am I still a valid X?)
postcondition: "Did I do my job, or what?"
Kinda like checking the customer's order to see if we carry those
widgets (precondition), checking inventory (invariant), getting the
widget (body), checking inventory again to make sure the books are still
balanced (invariant), and finally looking to see that what's in my hand
really is the widget the customer asked for (postcondition), before
handing the widget over the counter to the customer. That seems like the
correct order to do things, to me.
Just my opinion.
-- Dai
