[ruby-talk:04063] Re: require, ensure, and Design by Contract

> > In Eiffel, invariants are checked before *and* after the 
> > execution of an
> > *exported* routine ...
> > I do not have the rationale available in my mind right now ;-), 
> 
> Neither do I. Assuming there's no side-effects and we check the invariant
> after each call, I can't see how the object could be in invalid state when
> we enter the method. Well, anyway it's just an optimization to rip off the
> invariant check before precondition check. (And Ruby will allow weird
> side-effects quite probably, it's up to developer whether to mess around :).

Consider an object that needs to make a transition from state A to
state B, but has to do a non-trivial amount of work to make the
transition.  So it calls a bunch of internal methods that tweak the
state until finally we arrive at B. While we're executing these methods 
our member data may not yet be consistent so any invariant checks will
fail.

I ran into these sorts of problems with my first cut at DBC in C++.
They're pretty annoying: if all methods check the invariant you wind up
having to significantly weaken your invariant.

  -- Jesse