Charles Hixson <charleshixsn / earthlink.net> writes:

> Ryan Pavlik wrote:
> 
> >On Fri, 14 Mar 2003 13:00:07 +0900
> >"Jason M Jurkowski ;002;icsg6;" <jmj8237 / cs.rit.edu> wrote:
> >
> ><snip>
> >  
> >
> >>exactly.  i believe  eiffel makes a big deal about them as part of "design
> >>by contract"
> >>    
> >>
> >
> >I believe "design by contract" is flawed, but that's another
> >discussion entirely.
> >
> DBC is probably flawed in the context of Ruby.  In Eiffel it makes a lot 
> more sense.  In Eiffel you know what type something is going to be 
> allowed to be.  In Ruby assertions would probably only mean something 
> like 'This isn't a kind of data I'm prepared to deal with", valuable 
> information, but not necessarily a sign of an error.  In Eiffel this 
> would be a design error.
I'm not so convinced of this. You do not need the type of a Paramter
always but definitly it's value. Assume you would have

def sqrt (n)
        ... return square root
it could make much sense to have
def sqrt (n)
        require n_positive: n >= 0

Other thing which could make Assertions very nice in ruby you could
check if all elements of a collection fullfill some conditions. And
you can guarantee on the other hand that you guarantee that some
things hold...

And well it could be good for documentation too. you just would run

ruby -e short_form my_ruby_file.rb 

and got a short form of the contracts of the features. 

The major advantae is that this can be checked during runtime with a
computer... Somethin like having a comment like this

def sqrt (n)
        # will calculate square root of negative n
        if n < 0 
         raise 


can not happen...

> 
> The main job being handled here is detecting errors, and figuring out 
> how to deal with them.  Eiffel is better at the first part, and Ruby is 
> better at the second part.
Well that could suggest that it makes much sense to add DBC to Ruby,
this to improve on the first part. 

Regards
Friedrich