Comments on: Adding Type Checking to Ruby

By: Russell Balest

Russell Balest — Fri, 03 Jun 2011 15:04:51 +0000

About 5 minutes ago while walking and reflecting on 5 years of Ruby and Rails programming, it occurred to me that static type checking, which I once worried about, has somehow, mysteriously become a forgotten issue in my domain. The kinds of runtime errors that most often occur in my world would not be prevented by static type-checking in any case – like unexpected data and logic errors. Granted I’m not writing aviation software. But, the larger irony is that the overall occurrence of bugs of any variety is a fraction of what it was when I was programming regularly in C/C++. The reason could be simply that I’m writing less lines of code, and thus have less chance of making errors. Another reason is that there are really only about half a dozen ‘types’ to keep straight in Ruby and similar languages. Whereas in C++ there are technically infinitely many ‘types’.

Nonetheless I can see where the above approach might be useful to me if one could enable it during development and then disable in production.

By: Jon Kern

Jon Kern — Tue, 15 Mar 2011 23:04:49 +0000

Cedric, while there may be some very *special* cases where you need an API call to be this rigorous, it is *not the norm* in Ruby. And for good reason, as this makes otherwise flexible Ruby turn into the bloated nightmare that are most static typed languages.

By: Cedric

Cedric — Tue, 15 Mar 2011 21:29:39 +0000

@Eric Monday,

The point is that you want to be told at compile time whether the arguments being passed respond to “+”, and the only way to do this is to specify a type.

By: Eric

Eric — Mon, 14 Mar 2011 15:35:27 +0000

Why do you care if the arguments coming in are a string? Surely all you care is that they respond to the + method and can be concatenated together. Why limit yourself to only supporting strings? The type is not the issue – the methods that the objects coming in support are what matters. Quack quack quack.

I appreciate it is only some simple example code – but my point still stands. Or does it?

By: Guilherme Garnier

Guilherme Garnier — Fri, 18 Feb 2011 10:42:27 +0000

I understand the value of refactoring tools like Eclipse´s for static typed languages like Java. I use a lot of these refactorings with Java, and I think they are very helpful, but renaming methods and attributes isn´t 100% guaranteed, even in Java:

1 – if you use JSF or Spring Webflow, you have Java code called from XHTML and XML files
2 – if you do Criteria queries with Hibernate (not JPA 2.0 style), you write code like this:

criteria.add(Restrictions.eq(“name”, “John”));

Your refactoring tool won´t find your “name” attribute inside a string.

3 – If you use Reflection, you´re pretty much in the same situation as in a dynamic language.

I know IntelliJ refactorings are more advanced than Eclipse´s, but I don´t know if they can cover the 3 situations above (maybe the first one).

By: Jon Kern

Jon Kern — Thu, 10 Feb 2011 04:40:38 +0000

Daniel, while I can appreciate your point of view, I think it is misguided. I would advise against doing it except under very strict circumstances (I found it in 3 spots in my production code on one healthcare project — all having to do with message handling and checking what we received…).

More here: http://technicaldebt.com/?p=735

By: Nucc

Nucc — Wed, 19 Jan 2011 18:55:41 +0000

I guess this type checking is not a bad stuff, and yes, it could be really slow in production environment. But it can be very good under development, when it acts like an assert in C or C++. In Rails I have very usual String Integer comparing problem, that is very annoying sometimes, because printing it out shows good result (it calls the to_s method of the Integer on debugging).

By: Ragmaanir

Ragmaanir — Thu, 22 Apr 2010 15:27:25 +0000

I have to underline Martin Vahi’s comment. I also have been using ruby for quite some time as well as c++, C#, Java (and i have some experience in Scala, Prolog, Scheme etc). And i also saved a lot of development and debugging time because type checking caught errors as soon as possible so i did not have to spend hours searching for the origin of the errors. I would like to see some extensions to the type checking framework for attributes:

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

By: Martin Vahi

Martin Vahi — Fri, 26 Feb 2010 23:09:34 +0000

As of February 2010 I’ve been using Ruby for a few years, I’ve also worked in Java, Delphi and had C++ as my favorite programming language in the past. I specially loved to do speed optimizations and play with template metaprogramming. (That is to say, I’ve had many “religions”.) I’m not sure that I have fully understood the main values of duck typing, mainly due to lack of experience with it, but as I have spent about 7 months working with PHP(5) and JavaScript, mostly JavaScript, it seems to me that in practice run-time type checks for simple types like strings, hashtables, arrays, integers, has saved me a lot of time.

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)

By: Roger

Roger — Tue, 23 Dec 2008 18:27:26 +0000

http://74.125.95.132/search?q=cache:_7SQZf5WRQQJ:www.cs.umd.edu/~jfoster/ruby.pdf+ruby+static+parameters+library&hl=en&ct=clnk&cd=2&gl=us
lists an attempt at compile time ruby checking. That’s cool.