It seems that you could only pre-assert that objects going in
had a certain range of values that fit the requirement. The
above example wouldn’t work because it depends on the result
of a method call.
In the usage I described, only preconditions should go into the :pre method.
If I were to design a contract for your example, I would suggest …
def greet:post(other_person)
if shake_hand(other_person) == not_clammy
assert other_person.married?
Assert_equal self, other_person.spouse
assert_equal other_person, self.spouse
end
end
In other words, our post condition is that if the other person has an
acceptable handshake then we be hitched when the function is done executing.
Note that I’m using precondition and postcondition in a technical sense
defined by Design by Contract ideas. If you are not familiar with DbC, I
can recommend “Object Oriented Software Construction” by Bertrand Meyer (a
hefty read, but worthwhile), or one of Meyer’s shorter papers available at
eiffel.com.
···
–
– Jim Weirich / Compuware
– FWP Capture Services
– Phone: 859-386-8855
I will if I find time.
So, it’s really a contractual thing, not so much a logic thing. Doesn’t that
spread logic around anyway, though? I’m wondering what happens when the
actual method needs a parameter to pass another test, does the programmer
have to go open another file and assert the test there? It still feels like
spreading logic around that really belongs in one place.
Sean O'Dell
···
On Friday 21 November 2003 11:43 am, Weirich, James wrote:
It seems that you could only pre-assert that objects going in
had a certain range of values that fit the requirement. The
above example wouldn’t work because it depends on the result
of a method call.
In the usage I described, only preconditions should go into the :pre
method. If I were to design a contract for your example, I would suggest
…
def greet:post(other_person)
if shake_hand(other_person) == not_clammy
assert other_person.married?
Assert_equal self, other_person.spouse
assert_equal other_person, self.spouse
end
end
In other words, our post condition is that if the other person has an
acceptable handshake then we be hitched when the function is done
executing.
Note that I’m using precondition and postcondition in a technical sense
defined by Design by Contract ideas. If you are not familiar with DbC, I
can recommend “Object Oriented Software Construction” by Bertrand Meyer (a
hefty read, but worthwhile), or one of Meyer’s shorter papers available at
eiffel.com.
Yes, but arguably you’re changing the interface to the method/class at
that point so it’s analagous to
- opening up a separate .h file and changing it
- going to the top of the file (or wherever) and altering the types in
an interface declaration
···
“Sean O’Dell” sean@celsoft.com wrote:
So, it’s really a contractual thing, not so much a logic thing.
Doesn’t that spread logic around anyway, though? I’m wondering what
happens when the actual method needs a parameter to pass another test,
does the programmer have to go open another file and assert the test
there? It still feels like spreading logic around that really belongs
in one place.
–
Greg McIntyre ======[ greg@puyo.cjb.net ]===[ http://puyo.cjb.net ]===
Except you don’t open .h files to add logic, only to change declarations
(presumably). I rather prefer the way Delphi does it, but still, it doesn’t
happen often. I guess since checking parameter values wouldn’t happen often,
it would the same thing or close.
Sean O'Dell
···
On Friday 21 November 2003 03:52 pm, Greg McIntyre wrote:
“Sean O’Dell” sean@celsoft.com wrote:
So, it’s really a contractual thing, not so much a logic thing.
Doesn’t that spread logic around anyway, though? I’m wondering what
happens when the actual method needs a parameter to pass another test,
does the programmer have to go open another file and assert the test
there? It still feels like spreading logic around that really belongs
in one place.
Yes, but arguably you’re changing the interface to the method/class at
that point so it’s analagous to
- opening up a separate .h file and changing it
- going to the top of the file (or wherever) and altering the types in
an interface declaration