From: "Florian Groß" <florgro@...>
Date: 2005-12-29T23:20:01+09:00
Subject: Re: [ANN] (Real) Primitive Ruby Generics support

Isaac Devine wrote:

> Thanks! I've quickly looked at the ruby-doc for that. It's seems to
> only be able to specific "contracts" for classes, with method
> signatures as a subset. 

Hm, actually it provides a way of using unit tests for checking types, 
but will still let you do strong typing (via classes) and duck typing 
(via messages).

It then defines a way of adding type annotations to methods. Where types 
still means contract/class/message etc.

> [...] choose what code to execute based on method/class parameter types.
> [...] support to reading from a String when a class can only read from a File.
> [...] Another wish is for pattern matching: [...]
> 
> Looking at the rdoc some code in that could be very helpful - such as
> Contact.adapt. 

Basically at the moment I do type annotations for methods. So you could 
for example specify that you have a method that needs a Symbol and the 
Contract library would make sure that an exception will be raised for 
Fixnums -- it would however automatically invoke .to_sym (because there 
is an adaption route to Symbol for that) so Strings would work as well.

The problem with this is that all these conversions are explicit and 
that you can't define custom conversions that will just apply in the 
scope of your methods or classes. It's hard to find a good balance this 
way, because too much automatic conversion can very easily cause very 
surprising results.

I've not yet coded up multi method dispatch (which seems to be your 
primary goal for now), but it would be possible. For now you would still 
need to do the dispatching yourself by using ruby-contract's methods for 
checking whether your arguments match given types and then doing 
whatever you want to happen.

Pattern matching is interesting as well, but I can't think of a good 
implementation right now.

If you can come up with ways of integrating the functionality that you 
want in a clean way into ruby-contract then I'd be pleased to merge it. 
But even if it is hard to integrate this into ruby-contract's API feel 
free to build on the functionality it already has.

I tried hard to have unit tests with high coverage so reading through 
them might give you a bit more feeling of what is already there and how 
it can be used.

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