From: Ken Hilton <kenosis@...>
Date: 2002-08-07T07:42:25+09:00
Subject: DBC in Ruby.

Has anyone attempted to implement design by contract primitives in Ruby and
if so would you be interested in sharing your experiences with me?

Ps. Here's a copy of an email I recently sent to Matz on the subject -
perhaps you'd like to lend your support to my cause.

Greetings Matz,

[...]
    I imagine you are inundated with requests for new Ruby features and I do
not want to be just another email in your box naively asking for a trivial
enhancement to Ruby that could otherwise be achieved through a deeper
understanding of the language.  I assure you I have a sufficient
understanding of Ruby to venture the following request for an enhancement
that I believe would be very worth while; I hope you will feel likewise.
    In a nutshell, here is my request:  I would like to see native support
for Design by Contract in Ruby and in the very near future. Not to be one to
make a request without having put some thought into it, here's a few ideas
upon which a discussion thread could be based. Should you seriously consider
pursuing this idea, I would very much like to assist in the development of
the specification.

1) The model I would recommend, taking from Ruby's premise of drawing on the
best of other languages, is from The D Programming Language.

2) The Ruby method definition would be extended to support a precondition
and postcondition; either would be optional and if provided Ruby would
"ensure" the precondition and postconditions were evaluated in a well
defined manner. I would propose that the Ruby model be as flexible as
possible and perhaps instead of the pre/post conditions being Boolean in
nature, we leave it to the programmer to raise an exception within the
pre-/post- condition.  This would alleviate the need for the pre/post
condition to have a return value, i.e., if they return at all the condition
has been satisfied; on the other hand, also being Boolean in nature could be
useful and instead have Ruby raise a predefined exception when a pre/post
condition fails.  Some debate here might be useful.

3) The Ruby class definition would have support added for an class
"invariant". As in D, as I understand it, the invariant would be invoked by
Ruby automagically whenever a public method was entered and exited.  The
invariant would be private but visible to all members of the class in the
event the programmer wished to assert the invariant manually in
protected/private methods. The invariant would support the "super" concept
so that derivative invariants could over-ride parent class invariant or add
to them (by calling super), which is unlike the current D implementation, to
the best of my knowledge.

Well Matz, I'll stop here as I've taken up enough of your time before
getting an indication from you as to your interest in this enhancement to
Ruby. I sincerely hope you will consider it as Ruby combined with DBC would
provide a sorely needed solution to designing and implementing highly
reliable software and I for one would use this extensively.

[...]