RCR 168: Interface Checking

Of course Ruby is a dynamic language. I see nothing in the proposal that contradicts that. It sounds a lot less like static typing than something like optional soft contracts, which seems a reasonably Ruby-like answer.

type biggerthen4(x)

  unless x> 4
    raise
  end
  x

end
def somemethod(biggerthan4 x)
...
end
somemethod(3) # error

I said "soft contract", not strictly enforcable contract. That means the contract is cooperative only. When my method declares that it wants an argument that does :x, :y, and :z, then you have to supply it with an argument that "says" it does those things (ie, your argument is an object that declares those methods as part of its interface). Of course your object may be lying about its interface, or it may have the same interface but with incompatible semantics, and then all bets are off. No one is suggesting full bondage and discipline here. Even respond_to? is only such a cooperative contract anyway.

• there is a "type name" that can be referred to by programmers/documentation. "oh, that method takes an XYZ object"
  
• the "type name" of each parameter to a method can be queried at runtime
  
• all sorts of checking can be done in the "test", including kind_of or responds_to, but also extending to contractual obligations of the input argument. In fact it seems to be a complete "design-by-contract" implementation, ala Eiffel (not that I'm an expert in this area).
  
• it seems pretty trivial to disable the checking for production.
  

   It may be nice to perhaps have a flag that will make the interpeter pre-scan the source and output these kinds of potential errors, but not bother you with them when you run regularly. Technically in Ruby there is no need to define an interface, or to even define something like templates. Since things are typeless, the desired functionality of templates exists by default, as does the desired functionality of an interface. However for the purpose of writing code that is robust, and likely not to fail intermittently at runtime, it may be nice to provide utilities for figuring out what problems may occur.<br />
   Changes to Ruby should be carefully thought over, the last thing we want to do is turn it into a frankensteined language, like VB or C++.<br />

   I believe, still, that I understand what problem you're trying to address with this proscription.<br />

 def initialize(myObj)<br />
    if(Time.now.sec == 32)<br />
       myObj.oneMethod<br />
    else<br />
       myObj.theOtherMethod<br />
    end<br />
 end<br />

   def initialize<br />
   end<br />
   def theOtherMethod<br />
      puts('Ruby rules!');<br />
   end<br />

   It's often useful to implement an 'interface' in this fashion, it allows your code to be generic. However, when programming this, it's highly likely you'll never see the program crash due to the fact the programmer didn't complete the 'interface.' But, say he, the generic programmer, finishes this code, it seems cherry, and he sends it out to operate a heating-cooling system for a factory project. Goes home, sleeps, and while he's sleeping KABOOM! The system explodes because the program crashed. Okay, this probably isn't a highly likely occurrence -- but, in a statically defined language, this type of problem would be caught and not allowed. It may be nice to have a utility to profile the code to see if errors like this occur. Making the programs static is obviously not an option, and neither is just saying "Don't use Ruby in this fashion." This is a HIGHLY desirable effect. And I personally deal a great deal with real-world instruments, and often overlook Ruby. Not because Ruby isn't more efficient, or not fast enough, but because it's not safe enough. I know what people are going to say, "It's your fault that it isn't safe enough, you're a trashy programmer, etc.."<br />