Ruby, the interesting parts

A java developer's perspective

3 min readNov 22, 2015

--

Recently I decided to start learning Ruby just out of curiosity. I hoped it would eventually grow into doing some rails projects. For the past couple of months, I have been looking into its syntax and ways to do things, subconsciously comparing it to other languages I have already been familiar with. During the process, I came across some ways Ruby handles things that were compelling to me.

These are basic structures or otherwise just design decisions that caught my attention. I should note, though, that these are incomplete. This is rather just my thoughts on the topic while I was taking notes.

Method overriding

For a defined class, defining it once more or any number of times merges it with the other (earlier) definitions. The conflicting methods are overridden by the latest definition. In the following code snippet, the given method redefines the String class’s original replace method. The rest of String’s methods are still usable.

class String 
  def replace(str)
    self
  end
end

This comes from the fact that ruby allows us to define the same method more than once. Only the latest definition would be the actual one. Since the time I have written this, I have had the pleasure of looking into Swift and Scala too. They also allow this kind of class extension on a global scale. By extension, I mean adding methods or overriding and NOT inheriting.

Modules

A module is a block of classes, constants, and methods. This reminds me of the utility classes that we write in Java. Classes that cannot be instantiated, inherited, and contain a bunch of static constants and methods. As opposed to Ruby’s modules, utility class is not part of java language or SDK, but rather is a best practice.

Modules also have some similarities with java interfaces. One aspect that contributes to this is that module can be used as a type. Moreover, modules cannot be instantiated but can be ‘inherited’ or included by a class.

Just the same as a Class can have class and instance members, a Module can have module and instance members.

A Module as a Mixin

In contrast to an interface, a mixin can already contain some implementation. For example, Ruby has a Comparable module (Comparable interface in java). But unlike the java interface, the Comparable module has some implementation of quick comparison methods. It requires you to implement one method <=>, which is the same as the compareTo method in java. Scala has a similar construct which is called Trait. Both cases enable multi-inheritance-like behavior, that java designers chose to avoid.

The case where you try to mixin two different modules with the same name methods is one of the issues with multi-inheritance. Ruby seems to choose the version of the method that is from the last included module.

Besides, including a keyword, there is an extend keyword that seems to have a slightly different purpose. This makes it more ambiguous. Look into #5 for some examples of this. Though it does not give an example of a use case where extend could be useful

Do you have some more captivating parts to share? Please do.

Ruby, the interesting parts

A java developer's perspective

A Module as a Mixin

References

Written by Hafiz Hasanov