From: "Florian Groß" <florgro@...>
Date: 2005-04-29T21:22:10+09:00
Subject: Re: ruby static typing

Lyndon Samson wrote:

> I guess my point is there is alot of mistrust in the 'corporate' world
> as to whether dynamic/scripty languages are suitable for million+ LOC
> projects.
> 
> Type safety seems to be a big selling point at that scale, so being
> able to 'componentise' chunks of ruby by limiting coupling to using
> rigid interfaces might assuage some of that concern. Of course after
> the code executes post interface all bets are off with mutable
> classes/objects, allthough Object.freeze probably needs a bit of
> publicity here.

It has been suggested before that the right way of doing interface 
contracts in dynamic languages is to formalize them with unit tests -- 
that seems to work out quite well (RubyOnRails uses unit tests for 
assuring that new database adapters basically work).

There is however still cases where unit tests can not replace 
traditional typing -- as a simple example you might have a method that 
behaves slightly different depending on whether its argument is 
enumerable or not. There is more cases where handling types at run time 
would be nice -- type adaption comes to mind: For example you might 
write a method that expects something that understands a hash-like 
interface (keys, fetch, store, delete) and let your users supply Arrays 
and so on as well.

Of course you might argue that those cases don't appear to frequently in 
Ruby code and that seems to be true, but it still might be useful to 
have idiomatic solutions for them.

So, because of the fairly common requests for static typing in Ruby, the 
explorations of the Python community and just generic interest I decided 
to code some of this up. You can find the resulting (still quite 
experimental) library at http://ruby-contract.rubyforge.org/

This library indeed combines unit testing with type checking and while 
it lets you use instance-of checks (it is generally compatible with all 
checks that can be used in  case .. when  statements) their use is 
discouraged in favor of actual implementation testing. (Which is like 
duck-typing, except that it does not only check names, but also behavior.)

Perhaps this will do what you want, but even if it doesn't: Ruby has not 
had static typing so far and because of that it is a more productive 
language IMHO. I'm not encouraging carelessly written code, but Ruby 
just happens to have other preferred ways of ensuring code quality.