Understanding Ruby, part I

This is the first of some posts I’m planning to write about my discoveries with this environment

I’ve been learnin Ruby for a Rails project I started a few months ago, so far the project integrates mongoid and devise (for a complete explanation about how to integrate them you can find the sources1 at the end of this post).

This is the first of some posts I’m planning to write about my discoveries with this environment, so I want to start with the basis, RUBY

Ruby was created by Yukihiro Matsumoto in 1993 but its first public release was in 1995, during this time Yukihiro develop a language based on his spectations and philosophy which is the Principle of Least Surprise; the best way to explain it is with his own words

Everyone has an individual background. Someone may come from Python, someone else may come from Perl, and they may be surprised by different aspects of the language. Then they come up to me and say, ‘I was surprised by this feature of the language, so Ruby violates the principle of least surprise.’ Wait. Wait. The principle of least surprise is not for you only. The principle of least surprise means principle of least my surprise. And it means the principle of least surprise after you learn Ruby very well. For example, I was a C++ programmer before I started designing Ruby. I programmed in C++ exclusively for two or three years. And after two years of C++ programming, it still surprises me2

To make this long story short3 Ruby is a derivation of Perl, Python, Smalltalk and Lisp making it a language with royal legacy.

But let’s move to the language itself to understand it, I’m not going to detail code implementation, I’m going to explain how to understand its concepts.

This introduction is kind of liquid, it will explain several concepts in a chaotic way ;)

Ruby is an OO language, everything is an object, there’s nothing like int, long, char as primitive elements

@string = 'ruby string' @string.class #this will return String

About comments, there are two kinds

# 'hashtag' for line comment =begin block comment, group the block with =begin and =end =end

One thing to notice is that =begin and =end must be written without tabs

Symbols points to the same object in memory. The best way to describe this:

A symbol is all about who it is, not what it is…Symbols can best be described as identities

Symbols are very useful when you create attribute classes. It is possible to reduce the class verbose declaring the setters and getters

class Person  
  attr_accessor :name    # both getter and setter  
  attr_writer   :country    # just the writter  
  attr_reader   :id    # just the getter  
  
  # method definition with id as param  
  def say_hello id  
    puts self.name   # getter method  
    puts @country   # calls the class variable, there's no getter  
    @id = id   # direct assignment to class variable, there's no setter  
    puts self.id   # call to getter method  
  end
  ...
end  

@p = Person.new  
@p.name = 'Ruby' # setter  
puts p.country # error, there's no getter  
@p.say_hello '0001'

As you can see you can work with symbols for getters/setters assignments, but this goes beyond, you can modify access the methods to work directly with them - metaprograming

...
def say_goodbye  
  puts 'goodbye' self.method(:the_real_goodbye).call  
end  
  
private  
def the_real_goodbye  
  puts 'see ya'  
end  
...  

As you can see in the previous code  above the method 'the_real_goodbye’ there a declaration for method visibility, the following applies to variables also

Everything under the visibility declaration will use act inside the declared scope, this in my opinion is a great way to promote clean code; if you don’t want an spaghetti of declarations you should declare them in an ordered way

The following post it will be about conditionals, loops, iterators, and probably blocks :)


1 Rails 3 + mongoid + devise (authentication)

2 Interview with Yukihiro Matzumoto, Ruby creator