Ruby parameter type confirmation

Question

Coming from a Java background, I am a little perturbed by Ruby's completely blasé attitude toward its method parameters. Whereas in Java I could guarantee that parameter x was the type necessary for the method to work properly, in Ruby I have no way of guaranteeing that x is an integer, a string, or anything else for that matter.

Example: if I wanted to write an absolute_value method in Java, the header would be something like

public static int absoluteValue(int x)

In Ruby it would be something like

def self.absolute_value(x)

In this example, in the Java code I can be totally sure that the parameter being passed in isn't "Happy Birthday!" but in the Ruby code I don't know that. How do I prevent this situation in Ruby so the code doesn't crash at Runtime?

Related question: http://stackoverflow.com/questions/177080/ruby-and-duck-typing-design-by-contract-impossible — Andrew Grimm, Jun 08 '11 at 04:46
These days, Sorbet exists as an option for adding static and runtime typing to Ruby. https://sorbet.org You can also use steep, though it's less mature. https://github.com/soutaro/steep — Connor Shea, Aug 11 '19 at 19:16

score 4 · Answer 1 · answered Jun 08 '11 at 04:03

Welcome to Ruby, Kvass. Hopefully you'll learn to love duck typing. You gain confidence in your code in Ruby by writing tests, not depending on type checking and compilation. You gain speed, flexibility, and readability by not having to define the types.

DigitalRoss · Accepted Answer · 2011-06-08T04:43:00.323

Heh, welcome to Ruby. I too worked in Java in certain past years and I really loved Java at the time.

Now, it's not correct to think of Ruby as lacking type checking. It has at least as much type checking as Java, it's just that types are allowed to change and so the checks are done at runtime.

Plus, all that crushing declaration boilerplate in the old languages is annoying. A type-checked application that doesn't get finished in time to be useful does no one any good. A type-checked program that's too verbose to read is likely to become obsolete.

And if a type doesn't get checked the first time you run your Ruby program, it may well be covered by your tests.

But if you don't test it, you have no idea if it works anyway, so the abstract knowledge that the method call types conform would not be nearly as helpful as you might imagine.

In any case, Ruby has proven itself pretty well at this point as a language. As a real-life platform, RoR has some issues with performance, both in speed and in memory use, but I don't know of any projects complaining about the dynamic typing and wishing they were slogging through getting RSI with some old verbose language.

score 2 · Answer 3 · answered Jun 08 '11 at 04:51

2

Come with me if you want to live.

a="String"
puts a.kind_of? Integer  # false
puts a.kind_of? String   # true

a=10
puts a.kind_of? Integer  # true
puts a.kind_of? String   # false

answered Jun 08 '11 at 04:51

Jake Jones

1,170
1
11
15

1

This, however, is not duck typing. In the Ruby community, this is commonly humorously referred to as *chicken typing*. – Jörg W Mittag Jun 10 '11 at 16:25

score 1 · Answer 4 · answered Jun 08 '11 at 03:59

Ruby is (almost?) always interpreted, so a type check specified in a method header will crash at runtime anyway. The "duck typing" behaviour (where an operation type checks if the object being acted upon has the right method) is part of the idiom of Ruby, and you shouldn't try to write Java in Ruby. Learn to write Ruby code instead.

score 0 · Answer 5 · answered Jan 17 '12 at 11:52

You can do a minimal level of method testing while still maintaining duck typing. To use the example from the book "The ruby programming language"

def +(other)
  raise TypeError, "Point-like argument expected" unless other.respond_to? :x and other.respond_to? :y
  Point.new(@x + other.x, @y + other.y)
end

This example is used to implement "+" operation on Point class which works with (x,y) cordinates. Rather than doing a other.is_a?(Point) - they've tested the method's implemented, which to me seems like a good option. One can argue that the "other" object might have x and y attrs meaning something different, which although a correct argument misses the point that I am just pointing to a middle ground. My approach is also tilted towards doing the addition directly and failing if someone passes a wrong type.

Ruby parameter type confirmation

5 Answers5