Massimiliano Mirra wrote:

>If verbs were always chosen for method names, this could be nice:
>
>    obj.can?(:mkdir)
>
>And this wouldn't be too bad:
>
>    def meth(obj)
>      continue if
>        obj.can?(:mkdir) and
>	obj.can?(:recurse) and
>	obj.can?(:list)
>	
>
>Or more concise:
>
>    def meth(obj)
>      continue if obj.can?(:mkdir, :recurse, :list)
>
That's interesting and I like it.  With a little tweaking it should be 
able to provide nice runtime diagnostics about what object was passed 
where, how it was defined, and why it failed.  That's usefull, because 
in some of my Ruby projects I have mistakenly passed the wrong object to 
the wrong function, and then of course things would blow up.  I'd have 
to hunt the problem down, and that wasn't always easy.  This would 
provide a little extra layer of insulation.

BUT....

 I'm still not sure this really solves the problem (it only helps 
diagnose it better).  The core problem really isn't guaranteeing you can 
perform an operation on an object.  Instead, it's guaranteeing that an 
object conforms to a specification before we let it loose to wreak havoc 
in the dynamic Ruby environment.

Here is an example:  

Let's say I write a library, and I have an extension point within my 
library.  You can write your own object and add it in as an extension to 
my library, as long as it conforms to certain conventions (i.e. 
implements certain functions with specific behaviors).  Now, you, the 
library user don't fully understand the scope of what you are doing and 
goof up one of the functions.  Depending on your program and the 
library, it's quite possible this function may rarely get called.  You 
can spend hours, days, weeks, months assuming there is no problem and 
everything works correctly.  Then one day, another user comes along with 
a slightly different configuration than yours and boom everything blows 
up in your face.

Of course, you COULD check for this using Unit Tests.  But can you 
guarantee that the end user will use unit tests and use them properly? 
 I would hazard a guess and say no, of course not.  I like to write 
libraries that make it as hard as possible for the user to shoot 
themselves in the foot, because I know from experience that *MOST* 
programmers (at least out of those I have worked with or gone to school 
with) out there just don't have the skillset I do and *WILL* screw 
things up long before I will, so it's usually up to me to prevent that 
from happening.

What can you do about this?  I just wrote up a whole proposal for a 
contract interface, but then I deleted it because I'm not sure of the 
ramifications of an upfront contract/interface implementation and Ruby's 
ability to dynamically add methods to a class.  So my real question is...

Why doesn't Ruby have some sort of Contract/Interface specification (ala 
Java Interfaces or Eiffel Contracts)?  Is there a technical reason that 
these aren't possible, or is it just a subject that has not been 
properly approached yet?  I've seen lots of discussion about static 
types and responds_to? method, but I think both of these are really just 
one small aspect of the much larger problem: guaranteeing up front that 
the library user implements the required functionality.

Bryan