against enforce

[Jonathan M Davis]

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