jstern / foshay.citilink.com (Josh Stern) writes:

> I personally believe that some form of strong typing is invaluable
> for large projects, but it makes quick development much slower, so
> Ruby is potentially a great compliment to strongly typed languages
> just for that reason.  But it would also be nice to have flexible
> facilities for typing and 'design by contract' that operate at run
> time in Ruby when in 'debug mode', and have little or no overhead
> when in normal mode - some run time device that is, say, comparable
> to the assert() macro in C.

Just FYI, there are at least two DbC packages for Ruby available.

However, I'm not sure what you want in a strong typing system.

If you mean static type checking, then I don't think you're going to
get there with Ruby. But then again, there are almost no strongly
typed languages with full static type checking: most have to resort to 
some kind of runtime cast to be practical.

In terms of dynamic type checking, you have more flexibility. As well
as a simple 'assert' based system, you _might_ be able to implement
some kind of system using (say) mixins to flag a particular interface,
and then check for the interface where appropriate. 

But... I came from a background where I believed strongly in typing. I 
was a Pascal bigot, and wrote C and C++ with as much static type
checking as I could persuade the compiler to perform. I was very, very 
nervous moving to Ruby.

I was wrong to be nervous. In the time I've been using Ruby, I can't
think of more than one or two times when I've been surprised by
passing an incorrect parameter type. In fact, I'd say the density of
"undefined method" errors in Ruby is far less that the TypeCast
exceptions that happen in Java when you cast stuff out of a
collection.

So, I respect what you're saying about typing, and I would have agreed 
with you a couple of years back. Now I'm not so sure. I'm looking
forward to gaining the experience with large Ruby programs to see if
this happy anarchy scales.


Regards


Dave