Re: Contracts (feature request)

Henrik,

Have you ever used Eiffel? This has probably the most complete implementation 
of contracts that ever made it into the mainstream (and then only just). And it 
was a big bear. Looked cosy and cuddly from a distant, but up close, ripped 
your arms off and ate you for breakfast. For example, changing a pre-condition 
on a certain object being null or not could cause a ripple of change to cascade 
through the code. Chasing through 100K LOC+ when this happened with an IDE that 
wasn't powerful enough (and, I may be wrong, but I don't know of any IDE today 
that adequately supports refactoring contracts).

If we make extensive use of Test Driven Development and aim for > 70% unit test 
coverage in our domain layer (unit testing 'glue' code is purposeless and 
creates brittle test suites; this is better doen with integration or acceptance 
tests), we avoid most of the headaches contracts help with. Besides, what use 
is a contract that fails at runtime? What are we going to do? That's write, 
clean up and shutdown. OK, there are exceptions - object browsers and plugin 
managers - but not many. Good test coverage of the simple couplings should 
mitigate this. Good test coverage has the significant advantage that is more 
documenting and descriptive than a contract - in other words, it solves what 
contracts were trying to solve (adding more information on correct usage to the 
class) and then some.

By far the commonest feature I've seen is the need to check for null pre- and 
post-. Indeed, the genii at JetBrains saw that, and created the cunning Null 
and NotNull Assertions. However, null checks can mostly be avoided with two 
simple coding patterns:-
(1) Make use of Scala's Option[X] class for things that ARE permitted to be 
null. Gets over about 80% of all cases.
(2) Make extensive use of the NullObjectPattern (better called the Unknown 
Object Pattern). I have used this extensively now on many financial systems 
(which have lots of tiny value objects [sensu Eric Evans] where the values are 
often unknown for one reason or another). Done well, it can be very 
communicative - eg add an UnknownInteger to an Integer and get UnknownInteger. 
It means behaviour for null objects can go where it belongs - in a class - 
instead of being scattered all over the code base every time the null could 
occur.

I greatly respect the Pragmatic Programmers, and have successfully used many of 
their ideas (often without realising it) but on the subject of contracts, I 
think they over egg the argument a bit.

However, given the above discussion, I would be in favour of having annotations 
(attributes) on fields and methods which could be used by the compiler to 
generate or embed code. This has the added advantage of rendering unnecessary 
most of what AOP tries to do...

Raph

http://rehersal.sourceforge.net





                
___________________________________________________________ 
Copy addresses and emails from any email account to Yahoo! Mail - quick, easy 
and free. http://uk.docs.yahoo.com/trueswitch2.html