Sean O’Dell wrote:
Doing a respond_to? for every method you need an object to implement is
tedious, especially when developing a collection of related functions, and it
doesn’t mean that the object does what it reports to do, nor that it takes
the parameters you expect. For example, if an object responds_to?(:open),
what does it open? A file by name? The end of a socket? Which? However,
if an object implements the :socket interface, then I know it responds_to?
:open, :close:, :read, :write, :select, etc. and I know exactly what
parameters to pass.These things are important. It saves a lot of code and headaches when you can
just ask “does this object implement this interface?” You might not find it
useful, but others definitely do. This is one of the things I think Ruby
could do very well and still retain its flexibility. Being able to query for
the signature of an interface, with some syntactic sugar to allow parameters
to require them (optionally) is very much, to me, The Ruby Way; fearless and
visionary. This should make everyone happy; people don’t lose their
flexibility and we get all the type checking anyone should need.So, although YOU might not need this, I and others do. I think this is also
one of those little things that would win people over to Ruby. Having
absolutely no solid type checking is a big turn-off for a lot of people, and
it’s what keeps them developing in C/C++, Java and so on. If they’re
contemplating learning a script language, this would definitely catch their
eye.
er…excuse me? but did you just not understand me? you want to create a whole new set syntatical stuructures to specify interfaces so we can do checks against those, in a purely dynamic language? D.N.C.
the “Duck Tape” 
notion I presented earlier uses the idea of code refection, such that it would be possible to query methods, and by extention objects, for a duck_signiture. this would be automatic and thus dynamic, in comparison to the static appraoch you present here.
-t0