In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote:
.
[valuable remarks
on scientific
evidence and so on]
.
.
>Finally, there's a camp that pushes static typing up a notch,
>practicing what's called "Design by Contract" (DbC). Languages like
>Eiffel and D incluce DbC facilities. With these, you add extra code
>that provides checks on the preconditions to a method invocation,
>postconditions when it exits, invariants for an object, and various
>conditions on a loop. This help with the DRY principle, as a good set
>of unit tests would check all these things before and after each test,
>so you'd have to code the checks (or invocations of them) for every
>method invocation in every test. With language support, you only code
>them once, and the compiler generates code to check them
>automatically. Again, people who use them swear by them - but have no
>hard data to back up their believes.
.
.
.
... and it's even possible, as has already been hinted
several times in slightly different aspects in this
thread already, to combine these concepts to yield, for
example, DbC practices with a dynamic language such as
Python ("Design By Contract for Python", PyDBC, Contracts
for Python, ...).
--
http://mail.python.org/mailman/listinfo/python-list
