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