Ruby, the interesting parts. A java developer perspective
Recently I decided to start learning Ruby just out of curiosity, that I hoped would eventually grow into doing some rails projects. For the past couple of months, I have been looking into it’s syntax and ways to do things and subconsciously comparing it to other languages I have been already familiar with. During the process, I have come across some ways Ruby handles things that were interesting to me.
These are basic structures or otherwise just design decisions that caught my attention. I should note, though, that these are probably incomplete and rather just my thoughts on the topic while I was taking notes and do not represent a thorough research or analysis.
Method overriding
In case of a class defined with two methods, 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 for example, String class’s replace method is redefined but the rest of it’s methods are still usable.
This comes from the fact that ruby allows to define the same method more than once, but only latest definition would be the actual one. Since the time I have written this, I have also had the pleasure of looking into Swift and Scala which also allow this kind of class extension on global scale. By extension I really mean adding methods or overriding and not inheriting.
Modules
Module is defined as a block of classes, constants and methods. This reminds me of utility classes that can be written in Java. Classes that cannot be instantiated or 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.
Module has also some similarities with java interfaces. One aspect that contributes to this is that module can be used as a type. Another contribution to being similar with interfaces, in my opinion, is the fact that it 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.
Module as a Mixin
In contrast to interface, a mixin can already contain some implementation. For example, Ruby has a Comparable module (Comparable interface in java). But unlike java interface, Comparable module has some implementation for quick comparison methods and requires you to implement one method<=>, which is the same as the compareTo method in java. Scala has a very similar construct which is called Trait. Both cases enable multi-inheritance like behaviour, that java designers chose to avoid.
The case where you try to mixin two different modules that have a method with the same name, is one of the issues with multi-inheritance. Ruby seems to choose the version of the method that is from the last included module.
In addition to include keyword, there is an extend keyword that seems to have a slightly different purpose. This makes it more ambiguous. Look into #5 for some example on this. Though it does not give an example of a use case where extend could be useful
Do you have some more interesting parts to share? Please do.
References
- http://www.railstips.org/blog/archives/2009/05/15/include-vs-extend-in-ruby/
- http://learnrubythehardway.org/book/ex40.html
- http://metabates.com/2011/02/07/building-interfaces-and-abstract-classes-in-ruby/
- http://matt.aimonetti.net/posts/2012/07/30/ruby-class-module-mixins/
- https://rubymonk.com/learning/books/1-ruby-primer/chapters/35-modules/lessons/79-getting-modular
- http://www.rubyfleebie.com/ruby-is-dynamically-and-strongly-typed/
This was originally posted at https://medium.com/@hasanoviz