Daniel Schierbeck wrote:

> Hmmm, I'm not too fond of the use of classes -- I'd like to use the 
> #to_* methods instead. Otherwise the dynamic typing will suffer.

Nope, not at all. ruby-contract uses the same adaption routes that Ruby 
uses:

>   # Built-in adaption routes that Ruby already uses in its C code.
>   adaption :to => Symbol,  :via => :to_sym
>   adaption :to => String,  :via => :to_str
>   adaption :to => Array,   :via => :to_ary
>   adaption :to => Integer, :via => :to_int

So if it expects a Symbol anywhere it will accept a Symbol or any object 
that has to_sym() and so on. In theory you could also add non-standard 
adaption routes (like String => StringIO), but when you add more and 
more of them you also add more and more sources of hard to detect bugs 
to your application.

> Perhaps this?
> 
>   def foo(<str> bar, <int> baz, <sym> bur); end
> 
> Although I still think this is more terse:
> 
>   def foo(str bar, int baz, sym bur); end

The downside of that is that you can't anymore use any expression. With 
eh <> syntax you can also do this:

def foo(<type_for(:foo, 1)> bar)
def foo(<foo bar> qux)

At least the last one can't be done without an explicit delimiter. It 
might be rare and exotic, but IMHO one of the great things of Ruby's 
syntax is that you can use arbitrary expressions all over the place.

-- 
http://flgr.0x42.net/