I just read once-more Julien Blanchard’s blog post about a type system for Ruby. As we all know, Ruby uses duck-typing. That means that Ruby doesn’t care what type an objects says it is, it cares about what the object can do. It’s one of the things that makes the language so flexible, it allows us to write code like that:
def my_length(obj)
obj.length
end
knowing that this code will work for any object that supports the #length method, regardless of its ‘type’. It means we don’t have to overload this method again and again to deal with different argument types, as we would do in a statically-typed language. it’s a beautiful thing, one of the very things that makes Ruby, well…Ruby.
I am surprised to see that there is a movement of people within the Ruby community who want to have a static type-system, including overloading, casting and other associated nasties. I developed code in C++ for over 12 years before I started learning Ruby. I spent a significant part of those 12 years fighting the language’s type-system, telling it things like
“hey, this object over there is a std::string but I want you to convert it to a char*, because that’s how someone declared it in a function signature, although they are essentially the same thing and it shouldn’t really matter because I only want to use its bloody length anyway”
I really, really don’t want to go back to this. I know, from experience with both, that static typing’s drawbacks far outweigh the benefits. I appreciate there are use-cases for static typing but, you know, for such use-cases go use Java, Scala or whatever other language floats your boat. Let’s keep Ruby truly dynamic.
To paraphrase Ben Franklin: “Those who are prepared to sacrifice permanent flexibility for temporary safety deserve neither!”
The impression I got from it is it wasn’t going to be “Strict” as much as it would be optional. Right now types are determined at runtime (instantly) and/or inferred. Having the option of Typing would enhance debuggers and performance time.
There is currently a gem available to write your own typing in a comment before methods and variables. I don’t remember what that gem is, but here is a similar one: contracts.ruby
Tom Stuart does a good job covering this in this conference talk: Consider static typing
DuckTyping
I believe many people don’t understand what duck typing is. (I believe you have it right.) If you are doing if statements and the :is_a? method then you’re doing it wrong.
I believe the Null Object Pattern is a perfect example of DuckTyping. You create a Null type of the object that will be used and then the receiver method/Object won’t check for the type… it just does its thing. If you give it the wrong Type of Object then it will fail. I believe this is the proper intent of DuckTyping. Duck quacks and NullDuck quacks.
And as I understand it DuckTyping is a Pattern.
For the record I’m not an expert and am majoritively self taught. So feel free to correct me.
I appreciate that it would, but I’m worried about what it will do to the language’s expressiveness and fluidity. Also, there’s no such thing as ‘optional’ typing. If one module / gem / piece of code you’re relying on uses typing then you need to use it too. The option is not yours to take.
Yes, that’s the one Julian is referring to in his blog
Too right, that’s one of the ways I can tell if some code has been written by someone who’s recently moved to Ruby from Java or C# (the other is by looking for if obj != false kind of statements LOL!)
Yes indeed, the NOP is a good application of duck-typing though it can be overkill sometimes.
I am a user of contract.ruby.
The reason of NOT using respond_to? is that naming is difficult and could cause false positive result.
I like the fact that it is optional by default (as long as Contract is not called) and quite flexible.
I hope Ruby will have similar “feature” and have “some” performance boost compared to existing gems.
