> I think programmer sanity is probably helped by not having such a
> `feature'. Reusing variables for different purposes is not at all what
> [not] `typing' is about, and as David suggested, you possibly mean class,
> not type. (singleton methods/whatever-you-want-to-call-them, for example?
> are they part of the type? or something else?)
> 
> The point of duck typing is that you don't need to/you shouldn't document
> the 'types', seeing no purpose to restrict your definition of what's
> considered valid input. Surely if the object responds in all the ways you
> ask it to, it's fit for the task?
> 
> Arlen


Arlen, 

Maybe I'm not in the correct mindset of dynamic programming. I've always
found it difficult to remember return values/parameter-types (i.e. classes)
for a large number of methods. Don't get me wrong, I would much rather use
Ruby at work than Java, but with a good IDE, Java's entire API is available
in pop-up windows AS YOU TYPE. While developing in ruby, I have several
rdoc's open in my web browser, files open in several terminal windows, and
an IRB session open, all for reference purposes when I'm working with
unfamiliar APIs.

Huw Collinbourne's Visual Studio plug-in (link posted in this thread) seems
to have a good, if not slightly cumbersome, notation for giving hints to
the IDE. I prefer a more compact Haskell-like notation (e.g. String *
Integer -> String), but at this point, any standard notation would be
useful.

> Surely if the object responds in all the ways you
> ask it to, it's fit for the task?

Consider the common case of something like DataStructure#remove(). Does
remove take an index or the object to be removed? Usually the API developer
supports one use case or another but not both. You should not have to read
the code to figure out which it is.