I'm posting a lot on this topic because I think we have people
approaching the issue from two different directions.

John Carter <john.carter / tait.co.nz> wrote in message news:<Pine.LNX.4.58.0405181209490.28204 / parore.tait.co.nz>...
> The tighter you constrain the interface, the less reusable it is. In the
> example I mentioned, the programmers had ruined the polymorphic behaviour
> of the library by internally squashing everything into two byte int's. If
> they hadn't done that, polymorphism would have allowed the library to work
> on _anything_ that inherited from Number. Including the floating point
> types I needed.

Inferrence duck-type checking doesn't constrain the interface
significantly.

Consider:

  def meth( arg )
    arg.each { |x| ... }
  end

Now, the type checker knows that arg *must* implement #each(), and
that each() should accept a closure, right?  So if call this method
from somewhere else with:

  ...
  othermeth( 2
  meth( 5 )
  ...

the checker should be able to warn me that this is probably not going
to work.  I'm imagining something like:

  $ ruby -c myprog.rb
  myprog.rb:53: syntax error
  myprog.rb:54: ducktype warning: "5" does not implement each()

An important aspect is that "-c" would check all of the code, not just
the parts that are more commonly used.  It will catch things that are
missed by unit tests.  It will find potential errors in your program
*before* you go into production.  It will cure cancer, clean the air,
and bring peace to the Middle East.

I don't want to have to declare variables any more than anybody else;
what I want is a smarter "-c" code checker to find potential errors.

--- SER