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 :)