• Kagamin <spam here.lot> Mar 28 2011
• Jonathan M Davis <jmdavisProg gmx.com> Mar 28 2011

Kagamin <spam here.lot> writes:

Jonathan M Davis Wrote:

 Whereas I _rarely_ use in contracts. In most cases, I favor exceptions, 
 treating my functions as API functions pretty much as long as they're public. 
 That's not always the best approach, but it's generally what I end up using.


So why do you need a feature, which you don't use?
Also if a feature isn't used, doesn't it mean it's useless?

 out, on the other hand, I don't use as much. It's not terribly common that 
 there's a good test to run on the return value of a function in my experience. 
 Upon occasion, it's useful, but rarely. Unit tests generally solve the problem 
 better with regards to testing output. They're still useful though - just not 
 commonly so.


If you don't prohibit contracts to check external data, you can enforce the
check at design time with out contract. How would you check that caller checks
received data?

Jonathan M Davis <jmdavisProg gmx.com> writes:

On 2011-03-28 04:56, Kagamin wrote:
 Jonathan M Davis Wrote:
 Whereas I _rarely_ use in contracts. In most cases, I favor exceptions,
 treating my functions as API functions pretty much as long as they're
 public. That's not always the best approach, but it's generally what I
 end up using.


 So why do you need a feature, which you don't use?
 Also if a feature isn't used, doesn't it mean it's useless?


1. I do use it sometimes, just not often.
2. Just because I don't personally use it much doesn't mean that it's useless.
3. The main place that in is supposed to shine is with inheritance trees. It 
handles contract inheritance.

 out, on the other hand, I don't use as much. It's not terribly common
 that there's a good test to run on the return value of a function in my
 experience. Upon occasion, it's useful, but rarely. Unit tests generally
 solve the problem better with regards to testing output. They're still
 useful though - just not commonly so.


 If you don't prohibit contracts to check external data, you can enforce the
 check at design time with out contract. How would you check that caller
 checks received data?


I'm afraid that I don't understand the question.

out contracts are intended to verify that the result(s) of the function are 
correct (return value, the state of the object if it's a member variable, 
etc.). That's not generally very flexible in that it implies that there is a 
test that you can run on the result of a function to determine that the result 
is correct _regardless_ of the input. I don't find that to be useful very 
often, but sometimes it is. More often what I need is to check that given a 
particular input, the function gives you a particular output. And that's a job 
for unit tests.

- Jonathan M Davis