Why ruby? part one – a classy class system

Posted by ochronus on May 21, 2009 in ruby, theory | 13 comments

This is part one of a forthcoming series about ruby – and why I love it. This first episode focuses on general ideas, concepts and philosophy about ruby and a gentle introduction to its class system.

So, why ruby? I’ve got to know a few languages during the years – I started out with Qbasic (lol) at the age of 14 (hey, it was 16 years ago…), then came Pascal, then assembly and to crown my old-era knowledge, I became quite good in C. Later on I studied a bit of Perl, C++ and Java and finally arrived to the new age’s Pascal: PHP. PHP is what I’m making a living of and it’s really not that bad despite my woes posted here on my blog. Since two years I’ve been also working with Ruby and this is the first language I could say I feel home at. It’s simple, straightforward, logical and also natural (these two things are frequently opposite!). While programming in ruby I feel I’m expressing my thoughts in a natural way and it feels good and easy. Whenever I have to construct or implement a very simple scripting task or a complex algorithm, the first language I reach out for is Ruby. It’s fast to test out some ideas (either as a full quick-and-dirty script or some stuff in irb) and I can produce quality code and solutions without much effort in it. My experience fully fits with this quote from Ruby’s creator, Yukihiro Matsumoto:

Often people, especially computer engineers, focus on the machines. They think, “By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something.” They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.

Ruby is said to follow the Principle Of Least Surprise which basically means it works like a human mind would expect it to work. This may seem an exaggeration, but during our daily work it’s very important to minimize the time and energy spent “translating” our ideas to the language we’re implementing them in – and Ruby is very good in this.

After this short introduction to its philosophy, let’s see our first real topic: Ruby’s class system.

First statement: Everything is an object in Ruby.

Well, almost: Some things are classes :) Anyway, even simple values are classes. Take the number 5, for example. Fire up irb (the interactive ruby shell/interpreter), and type 5.methods. The result is (ruby 1.8.7):

irb(main):001:0> 5.methods
=> ["%", "odd?", "inspect", "prec_i", "<<", "tap", "div", "&amp;", "clone",
">>", "public_methods", "object_id", "__send__", "instance_variable_defined?",
"equal?", "freeze", "to_sym", "*", "ord", "+", "extend", "next", "send", "round",
"methods", "prec_f", "-", "even?", "singleton_method_added", "divmod",
"hash", "/", "integer?", "downto", "dup", "to_enum", "instance_variables", "|",
"eql?", "size", "instance_eval", "truncate", "~", "id", "to_i", "singleton_methods",
"modulo", "taint", "zero?", "times", "instance_variable_get", "frozen?", "enum_for",
"display", "instance_of?", "^", "method", "to_a", "+@", "-@", "quo",
"instance_exec",  "type", "**", "upto", "to_f", "<", "step", "protected_methods",
"<=>", "between?",  "==", "remainder", ">", "===", "to_int", "nonzero?", "pred",
"instance_variable_set",  "coerce", "respond_to?", "kind_of?", "floor", "succ",
">=", "prec", "to_s", "<=", "fdiv", "class", "private_methods", "=~", "tainted?",
 "__id__", "abs", "untaint", "nil?", "chr", "id2name", "is_a?", "ceil", "[]"]

Wow, what a galore of stuff! But what are they? Well, they are methods of some class, of course! 5 is an object of class Fixnum:

irb(main):002:0> 5.class
=> Fixnum

Wait! Gotcha! You said everything was an object in Ruby! So what about this magic “methods” method that produced this nice listing above? Sure, it’s return value is an object of some class, too! Let’s see which class:

irb(main):003:0> 5.methods.class
=> Array

No surprise, we have an array here. Logical and straightforward: it’s just like property access in .NET & Co. We asked for the methods of the object 5 – it’s a list of strings of course. Wait, what methods do arrays have? Easy to check: 5.methods.methods :) I will spare you of the long list.

Notice something interesting in the listing I presented? What are those operator-like things there? Like “==” and “===”? Well, most operators are just plain old methods – even array access. This means that we can include some nice syntax for access of our own classes, like an array-like operation for a class which implements some caching api, or we can easily make or class objects comparable, addable, etc. without deriving them from some fishy ancestors or implementing interfaces or using lame method names like myObject.compareToAnother().

Another nice feature is the ability to extend existing classes and redefine methods. Yes, that’s true. I can easily define a “sum” and an “average” method for the Array class:

class Array
	def sum
		inject(nil) { |sum,x| sum ? sum+x : x }
	end
 
	def average
		sum.to_f / size
	end
end
 
puts [1,2,3,4,5,6].average
 
==> 3.5

Don’t care yet about the implementation of sum, we’ll cover inject and its friends in later posts. See the magic in this? I’m adding a method to a “system class”. I can even add methods to the Fixnum class or anything.

Ruby does not have namespaces, but it has something similar (and yet different) – Modules. From one side, modules are just plain old namespaces – grouping and separating things. From the other side however:
Ruby does not support multiple inheritance, but it does have something that’s called Mixins – mixins are just what the name suggests – adding features of modules to another class. For example, ruby already provides us with the module Comparable , and by mixing it in our class we get to use six comparison methods with implementing only one comparison operator: <=> (less than, equal to or greater than):

class Song
  include Comparable
  def <=>(other)
    self.duration <=> other.duration
  end
end
 
song1 = Song.new("My Way",  "Sinatra", 225)
song2 = Song.new("Bicylops", "Fleck",  260)
song1 <=> song2	»	-1
song1  <  song2	»	true
song1 ==  song1	»	true
song1  >  song2	»	false

That’s about it – a novice introduction to ruby and its class system – there’s so much more on this topic, but they are more advanced things which deserve a separate post near the end of this series. Stay tuned, and as always, thank you for taking the time to read my post – all comments, corrections and additions are more than welcome!