Kyley Harris wrote:
In this case the contract is that the code returns true to guarantee an
assigned object so that you don't need if assigned(value) in a whole lot
of places. The second part of the contract is that if it returns false,
you don't pretend that it was true and try to do something with an
invalid pointer.
Well, you can follow that path all the way to reinventing Eiffel ;) But below is the perfect example of what happens. Anything counting on side-effects is false prophecy, as I now must test that my list is assigned, and that my status is assigned, and test the result is true.
I'd rather just hire a tester.
We've gone from a function which
takes any list, any status and always returns an integer
through a function takes any list, any status, an integer variable
which will be changed, and returns a boolean
to a function takes a non-empty list, an assigned status,
an integer variable which will be changed, and returns
a boolean.
Okay, I'm ignoring the difference between returning a listitem
and an integer, but its the same argument either way.
Cheers, Kurt.
functionFindFirstMatch (List: TItemList; Status: TItemStatus):TListItem;
begin
if not assigned(List) then raise exception.create('No list assigned
for findFirstMatch()');
if not assigned(Status) then raise exception.create('No status
assigned for findFirstMatch()');
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi"
Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
