duck-type-checking?

[Craig Allen]

> This is better achived, not by littering the functional code unit with
> numerous assertions that obscure the normal function of the code, but
> rather by employing comprehensive unit tests *separate from* the code
> unit.

that doesn't seem to work too well when shipping a library for someone
else to use... we don't have access to the caller's code that needs to
be checked.  I suppose if the intent is to have a true assert, that
does nothing in shipped code, then you can argue that testing
addresses some of the issues, but one, not all of them, specifically,
not the part where the problem is ably reported, and two, I don't
think we can assume assert meant that sort of assert macro in C which
compiles away in release versions.

Asserts also do not litter code, they communicate the assumptions of
the code.  I like the idea of a general duck-type assertion and would
probably use that, especially since I also have arguments which can be
multiple objects, each with their own interface but similar meaning...
i.e. lower level file objects can be passed in, or my higher level
abstraction of the same file.