Richard Bucker

Ruby Contracts Gem - Contradiction?

Posted at — Jun 15, 2012

I continue to buzz Ruby like an Army Combat Drone. Recently I captured a post that caught my attention. The basic idea is:The addition of decorators to Ruby methods so that params and return values were of a particular type.To my knowledge the absence of a “contract” is actually a strength of Ruby, Python and Perl. In fact Python specifically recommends that one should not check the param types and that throwing some sort of type exception is preferred. (it in one of the best practices docs).The only reason I can fathom for this “Contracts” gem is so that programmers coming from strongly typed languages (java, c, c++) can transition easier. The only problem is that there is no place for this sort of coding when on a team of experienced programmers in that particular language. The establishment is going to have it’s way of doing things and it will be on the new guy to assimilate.Here is a perl edge case:[sourcecode language=“perl”]sub add($$) {    my ($a,$b) = @;    return $a + $b;}[/sourcecode]And here is the preferred version:[sourcecode language=“perl”]sub add {    my ($a,$b) = @;    return $a + $b;}[/sourcecode]Notice that the difference is that the ($$) has been removed from the first example. The reason being that it is redundant as the first line of the function ismy ($a,$b) = @_;and it sufficiently describes the function.“Contracts” is less of a bridge and more of a beaver damn.