attr count: Integer, default: 0
attr name: [Symbol,String]
attr enabled: Boolean # => generates method: enabled?

If a method has to receive a string or a hashtable, but due to a typo or my fuzziness receives something else, then it saves considerable amount of development time, if that error has been reported. On the other hand, in the “duck typing” side I actually “study the duck” more thoroughly in the debug mode. For instance, whether the hashtable/object instance has all of the required fields, whether their values are within the domain, etc. Actually, in the case of my JavaScript code, the type checks for the simple types, string, int, etc., occur only in debug mode. So, I think that the truth relies again somewhere in between. As of February 2010 I think that It’s good to have some type checks, but it should be optional and in “the appropriate place”.

Regards,
Martin (Vahi)

It certainly is, but there’s no reason that the checks have to be done in production code. For example, it’s quite possible to move the assertions off to a separate “library”, running them only when the code is being tested, etc. I have a proof of concept for this approach at http://cfcl.com/twiki/bin/view/Projects/Spect/UC_Method_Calls

http://beust.com/weblog/archives/000414.html

–
Cedric

—– ‘dog.rb’
class Dog
def makeSound
return “woof!”
end
end

—– ‘cat.rb’
class Cat
def makeSound
“meow”
end
end

—– ‘animal_sounder.rb’
require ‘dog.rb’
require ‘cat.rb’

class AnimalSounder
def main
animal = Dog.new
puts animal.makeSound
animal = Cat.new
puts animal.makeSound
end
end

(AnimalSounder.new).main
—–

Now, if I rename Cat’s makeSound or Dog’s makeSound to “makeNoise”, this isn’t picked up in the other files.

If I move Cat into the same file as AnimalSounder, then renaming Cat.makeSound does suggest that “animal.makeSound” in AnimalSounder be renamed, in both cases (for dog and cat)! Then I can *manually* select the case where I want it to be renamed.

Refactoring nothing to do with static typing? Lets take the most basic refactoring there is: renaming a method. This is fully automatic in any modern Java IDE and takes only a few seconds even if the method has hundreds or even thousands of uses. And the ability to do this so easily actually gives the code a more “dynamic” property in the sense that it can changed easily (unless you have already released it to clients as API). Resistance to change is minimized and the changeability of code is incredibly important in my opinion. But in my experience, some Java programmers still aren’t fully accustomed to this power and still resist changes to code.

Can a Ruby IDE do the same and guarantee that all the possible uses of the method, or any code that relies on that method, will be renamed correctly? Somewhy, I don’t think so, but if I’m wrong, then I raise my hat to the IDE developers. (of course, even in Java, use of the method by reflection isn’t refactorable [to my knowledge no IDE tries that], but that is rare anyway.)

I’ve seen a Ruby user claim that renames aren’t necessary in Ruby because the code is so good from the start — I call bullshit on that, all code needs to evolve and change and no one creates perfection from the start (or at all, actually).

Second, even with this type checking framework, you -still- need to do extensive unit testing to prevent type errors. Unless you want your production system to throw a runtime type error and crash.

Third, type checking is done at -every- method call? A good static type system checks types once… at compile-time. Making a type check for every method call sounds like massive overhead.

Overall, I think, you gain little (better runtime error messages) and lose much (worse performance, extra verbosity). For writing Ruby code, I’d stick with unchecked dynamic types.