And I would also like to discuss the trade offs between pre/post/invariant
failure causing Ruby to raise a corresponding exception vs. the
pre/post/invariant themselves raising a specific exception which is
indicative of what sub-condition was actually violated. There are merits to
both approaches, as I see it.

Ken.

"Yukihiro Matsumoto" <matz / ruby-lang.org> wrote in message
news:1028694505.982448.15154.nullmailer / picachu.netlab.jp...
> Hi,
>
> In message "Re: DBC in Ruby."
>     on 02/08/07, "Justin Johnson" <justinj / mobiusent.com> writes:
>
> |In my version of Ruby, I'll be making sure that there is no performance
> |penalty if dbc is turned off.  I intend to do this by slightly modifying
the
> |bytecode for methods when you call the dbc enable/disable method.  It's
> |possible to change the method bytecode start address and insert a return
> |before post and invariant calls to disable dbc with no loss of
performance.
> |
> |Thing is, I'd hate to implement this and then find out that Matz has
> |implemented a different scheme for his next version!
>
> Pretty interesting.  Let's discuss before the chance we take different
> path.  How much should syntax help DbC?  How should the core help DbC?
>
> matz.
>