From: "vidar.hokstad@..." <vidar.hokstad@...>
Date: 2006-02-09T00:23:22+09:00
Subject: Re: Meta-Meta-Programming

Austin Ziegler wrote:
> That's what documentation is for.

People don't read documentation thoroughly enough.

And even if they do, that still leaves them with a major testing
headache if artificially creating the corner cases that triggers
specific behavior from your code is hard to do.

Relying on the documentation for something that is easy to check is a
cop out. _Especially_ when it is trivial to turn that check off for
production code and remove all cost.

> Except that contract enforcement is *expensive*, and most contracts are
> much more difficult to express than can be expressed in the way that
> people who are (foolishly) comforted by static typing expect.

Many contracts are expensive yes and many aren't - I have lots of code
that depend on a single or a small set of methods to be available on an
object that is passed in. Checking it is easy. Even so, I've pointed
out that one of the things I liked about the wrapping is that it's
trivially easy to make it optional at runtime at no cost.

The wrapping approach has the advantages that:

 - The checks can be put in a separate source file and only included in
the application when you want them (or you can keep cheap checks in
critical parts of the code, and keep more expensive checks or checks on
less critical code separate and not use it in production code)
 - The checks can be trivially disabled in a such a way that there is
_no_ cost when the methods are executed (by simply switching the
wrapping off)
 - It's trivial to expand the checks without making the core code more
complex
 - It doubles as documentation that you know will be kept up to date
because things will break if it isn't. If there is one thing I NEVER
trust, it is documentation that isn't executable - it invariably gets
out of date, blatantly wrong, and outright dangerous to depend on.
 - They assist in minimising the effort of writing test code for
clients of your code, by minimising the number of potential code paths.

This has nothing to do with being "foolishly comforted by static
typing" but about 1) facilitating testing and debugging, 2) avoiding
late surprises, by failing early where possible, both of which are
good, sound practices regardless of whether you use static or dynamic
typing.

Vidar