I made a simple list describing the 3 main things to consider when trying to understand how objects work in ruby. Feel free to add to this list as much as you want. Your comments are welcome and very appreciated.

1) The starting point is the object, not the class

To understand how objects and classes behave in ruby, we have to stop thinking in terms of classes and start thinking in terms of objects. Why? Because in ruby, a class is also an object. Every classes you are defining are instances of a class named Class. Each of these instances contains everything related to the structure of the object. Only one instance for each class definition is needed in a typical ruby / rails application. I mean, there would be no need to have both String.new() and String2.new(). Just one factory to create String instances is enough. However, if for some strange reason you would like to clone the definition of a class in another instance, you could still do it.

String2 = Class.new(String)
my_string = String2.new("How useful!")
my_string.reverse

2) An object structure is not frozen and can be altered at any time

When you’re done defining your class and you put the end keyword, don’t think that this object (remember, a class is an object) is “safe” from future modifications, it isn’t. Everyone can modify your class structure. I know that dynamic languages are not for everyone (I imagine Java and C++ programmers shaking their heads in desperation right now…), but I personally find the freedom that they offer to be truly amazing.

class NoOneIsSafe
  def my_method
    "I'm in my_method"
  end
end
#Now, let's create a mess
def im_hacking_this_object!
  "Muhahahahaha!"
end
#I just realized that the following code does not what
#I really thought it would. Read the update below
NoOneIsSafe.send(:public, :im_hacking_this_object!)
obj = NoOneIsSafe.new
obj.im_hacking_this_object! #output : Muhahahahaha!

#UPDATE 03/30/2007
Even if the above code really changed NoOneIsSafe structure, I realized that it also changed the structure of every single instances! Whatever you write some_obj.methods, String.methods, MyCustomClass.methods, you will see the im_hacking_this_object! method everytime. It’s definitely NOT something a sane person would want to do.
You could also add a method to a single instance of an object, like this :

class NoOneIsSafe
  def my_method
    "I'm in my_method"
  end
end
obj=NoOneIsSafe.new
obj2=NoOneIsSafe.new
def obj.my_other_method
  "I exist in this instance only"
end
obj.my_other_method #it works
obj2.my_other_method #won't work

3) Things that don’t look like objects often are

When trying to understand how objects work in ruby, you have to put the following sentence in the back of your head at all time : “Objects are everywhere… even if I can’t always see them“. A trivial statement like result = 5 + 3 must be understood the following way :

• The “+” method of the Fixnum instance named “5” is called
• The Fixnum instance named “3” is passed as a parameter to the “+” method.
• The result of the call is a FixNum instance and is assigned to an object called “result”, which in turn becomes a FixNum instance

I talk about those hidden OO mechanisms in the following articles :
– Oh Ruby, who are you trying to fool?
– A trap to avoid with Ruby assignments
#UPDATE 03/31/2007
Gary Wright pointed out that you can only have one instance for a given Fixnum. For example, if you write :
a=1
b=1
c=1
1, a, b and c will all point to the same space in memory (Actually, these are not 4 different references to the same object. they are the same object). When you write 5 + 3, 5 already is a FixNum instance. The name of this instance is 5. Thanks to Gary for clearing this out.

Symbols in Ruby are used everywhere and for good reasons. There are two main reasons of using them instead of strings (however they are absolutely not a replacement to strings, more on that later).
1. Semantics
When you write :dog, it is clear that you are refering to something. On the opposite, when you write “dog”, it only looks like the letters d, o and g. If you remove the double quotes, dog magically gets a meaning.
2. Efficiency
When ruby sees a symbol for the first time, it creates a space in memory for it. Every other use of the same symbol will refer to that space instead of being allocated a new one. Same thing, same place.
This is all fine and dandy, but what are symbols exactly?

A symbol is an instance of class Symbol

In this regard it isn’t different than any other ruby object. The way it differs is in how you use the object. A Symbol instance is used differently than an instance of an other class. First, you cannot create a Symbol instance that way :

my_symbol = Symbol.new() # <== won't work!

To create a new Symbol instance, you simply have to use it like if it already existed. When ruby parses your code and finds a symbol for the first time, it creates an instance for it. The next time it will find the same object name (the name of the symbol) in your code, it will use the same space in memory (like any other object!).
So, to summarize : A symbol is simply an object with a special naming convention. The convention is that you must precede your symbol name with a colon ":" so ruby can understand that you want an instance of the Symbol class. Since Symbol.new() doesn't work, there had to be some way to create an instance of this class... that's exactly the purpose of the ":" character.

We don't care about what's contained inside a Symbol instance, we just care about it's name

While there are several instance methods you can call in a Symbol object, most of the time you are only interested by it's name. The purpose of a symbol is to centralize a meaning. You want to create names that will have a meaning for you and other programmers who may have to deal with your code later. You can think of symbols as an application wide registry table with 2 columns. The first column being the symbol object id (ex : 243938) and the second column being an associated name (ex : dog). Since we are humans and words have more meaning than numbers, we use the 2nd column to refer to a symbol.

Assignments

If you access a symbol directly, that is with the :symbol_name notation,you can't assign to it. It wouldn't make a lot of sense anyway. It's like if you were saying that the left object was a symbol and, at the same time, that it was a String. However, if you assign a symbol to an object, future assignments to this object are allowed.

:my_symbol = "blabla" # <== won't work!
container = :my_symbol # <== that's ok
container = :my_other_symbol # <== that's ok
container = "not a symbol" # <== that's ok

Comparing symbols to strings

If you write :dog == "dog", ruby returns false. It is because you are comparing a string with a Symbol instance. It just cannot be the same. If for some reason you would like to check if some string is equal to the name of a symbol, you would have to write :dog.to_s == "dog". Most of the time however, you will compare a Symbol instance with another Symbol instance.

my_var = :my_new_symbol #symbol created and assigned to my_var
my_other_var = :my_new_symbol #SAME symbol assigned to my_other_var
puts my_var==my_other_var #it's true!
puts my_var==:my_new_symbol #it's true!

Symbols are not better strings

Strings are all about content, symbols are all about meaning. When you write "dog", the three letters are the only things that matter. If you decide to use the String form of a "dog", it should be because you want to display the 3 letters on the screen or manipulate them in some way (capitalize, chomp!, reverse etc). When you write :dog, it is what a dog represents to your application that matters, not the individual letters. We only use words to define a symbol because we cannot use mental images (ruby is great, but that would be asking a bit too much...).

Symbols in hashes

You are probably comfortable using symbols with hashes already. animals[:dog] = "charlie" is something you see really often in ruby programs. As you might know, what the statement animals[:dog] = "charlie" really means to ruby is animals.[]=(:dog,"charlie"). The first parameter is a Symbol instance and the second parameter is the new value you want to store in the hash at the position associated with :dog. Every items in a hash are represented by a key and a value. In this specific case, the key is a Symbol instance. The []= method checks if there exists an item in the collection with the key part equals to the Symbol instance :dog. If it is the case, the 2nd parameter "charlie" is assigned to the value part of that same item.

Another thing that’s pretty confusing for ruby new comers is the assignment operator (the “=” sign).
When you write something like : my_obj = MyClass.new, the “=” sign does what you think it does. However, when you write : my_obj.yadayada = “123”, it doesn’t (Ruby has a tendency to fool people).

Why is this second form of assignment any different?

In the second example, it seems like we are trying to set the attribute yadayada of my_obj, but that is impossible because ruby doesn’t allow this. As soon as it sees the dot after an object name, it expects to see a method, nothing else. Ruby doesn’t want you to play with the attribute of an object directly, it wants you to call it’s accessor methods.
If that is so, why didn’t Ruby complained when we wrote my_obj.yadayada = “123” ? It is a clear attempt to set an object attribute directly! Hmm, maybe it isn’t. Look closely. As much as it looks like a standard assignment, it is indeed a method call. When you write my_obj.yadayada = “123”, Ruby understands : my_obj.yadayada=(“123”). The “=” sign being the last character of the method name, that is : yadayada=.
If you don’t define the yadayada= method in MyClass, Ruby will complain by raising the following exception :
NoMethodError: undefined method ‘yadayada=’ for #MyClass:0x2c9be70.
As you can see, it is expecting a method, nothing else. That’s why you have to name your attribute writers with a trailing “=” if you want to give the illusion that an assignment occured. As for attribute readers, you have to give them the same name as the real attributes.

class MyClass
  def initialize()
    @yadayada = "initial value" #The real attribute
  end
  #Attribute reader
  def yadayada()
    @yadayada
  end
  #Attribute writer
  def yadayada=(some_value)
    @yadayada=some_value #real assignment! no more fooling
  end
end
#using the class
my_obj=MyClass.new()
puts(my_obj.yadayada) #calls the instance method "yadayada"
my_obj.yadayada = "some value" #calls the instance method "yadayada="

Congrats, mister Copperfield, the illusion is perfect! I’d like to point out that if the only thing your accessors are doing is to respectively get and set the real attribute value, you could use one or more of the following helpers at the beginning of your class : attr_reader, attr_writer and attr_accessor. For example, if you write attr_accessor :yadayada, your two accessors for the yadayada attribute will be created automatically for you. If you only want an attribute reader, use attr_reader. If you only want an attribute writer, use attr_writer.

A last twisted case

What if we write : my_hash[:my_key] = “some value” ?
It looks like a “real” assignment don’t you think? How can a method be named “[:my_key]=” ? It doesn’t make any sense. Well, I know… but ruby did something funky once again.
Question : What is the method name in my_hash[:my_key] = “some value” ?
Answer : []=
No kidding, []= is an instance method in the Hash class.
If Ruby was evil, it would force us to write the last statement in the following way : my_hash.[]=(:my_key,”some value”). We would all become completely crazy and it would be dangerous to our health. Fortunately, Ruby isn’t evil, it is our friend. It let us refer to our hash in a comprehensive manner so we don’t lose our mind. Then, it does some tricks we don’t want to know in the background that will transform :

my_hash[:my_key] = "some value"

to

my_hash.[]=(:my_key,"some value")

Phew… you won’t have to use the 2nd form, ever. I wonder what would people say about ruby if it was the case. But just in case you’re curious or doubtful, run IRB and write the following :

apple = {:color => "green", :variety => "granny smith"}
apple.[]=(:color,"red")
apple.inspect

If you’re somewhat familiar with ruby, there are good chances that you won’t learn anything new and exciting in this article. However, if you’re new to the language or just didn’t have time to take a look at ruby hashes yet, maybe you should continue reading.

What is a hash ?

A hash is a collection of objects, exactly like an array. The difference with arrays though, is that the indexes of a hash are not represented with integer values (FixNum instances). Instead, the key can be an object of any type! This means that instead of accessing your hash this way : result = my_hash[4], you can access it this way : result = my_hash[‘the_thing_im_looking_for’] or, to do things in a more rubyish manner : result = my_hash[:the_thing_im_looking_for]. To create a new hash from scratch, you just have to specify the various key/value pairs and separates them with the hash literal “=>” :

animals = { :dog => "charlie", :cat => "kwiki", :mouse => "squeaky" }

Why should I use hashes ?

One of the obvious advantages with hashes is their readability. When you write animals[4], it’s quite hard to see which animal you are trying to get. When you write animals[:dog], it becomes pretty obvious. A maybe less obvious but extremely useful thing about hashes is that you can improve the way you pass parameters to your methods by making them more flexible. When you use this technique, the order of the parameters becomes totally irrelevant! Ruby helps you along the way to achieve this. Let’s see how :
First : let’s take a look at the method call

dance_like_an_idiot(:frequency => "every minute",
			   :idiocy_level => "REALLY idiot",
			   :risk => "losing credibility forever")

Now, let’s take a look at that dance_like_an_idiot method

def dance_like_an_idiot(params)
  puts(params[:frequency]) # writes "every minute"
  puts(params[:idiocy_level]) # writes "REALLY idiot"
  puts(params[:risk]) # writes "losing credibility forever"
  #instructions to start the idiotic dance
end

The first thing you’ll notice is that even though you passed 3 parameters to the method, that method accepted just one. What is going on here? Well, you know ruby is your friend and that a friend is always there to help you, right? Well, in that case you won’t be surprised to learn that it did something really cool for you in the background. The other thing you will notice is that we passed our parameters in an unusual way to our method. For each parameter, we specified a key/value pair separated by the “=>” literal. If you remember, it looks really similar to the way we created our hash from scratch earlier in this article. In fact, that’s exactly what happened. The one difference is that we didn’t assign the key/value pairs to an object. The twist is exactly there : Ruby did it for you (I told you he was your friend). Ruby created an “anonymous” hash on the fly with the key/value pairs you specified when calling the dance_like_an_idiot method. The new created hash then has been passed to the params parameter at the receiving end. From there, the dance_like_an_idiot method was able to use the hash in any way it wanted to.
The great thing about this technique is that you don’t have to care about the order in which you pass your parameters to a method because those parameters will get merged into a single hash anyway. You can even omit to specify a key/value pair and the method will still be called (if the method tries to use an item in the hash that hasn’t been specified by the caller, it will in fact be dealing with a nil object (external link)).
You can also pass both standard parameters and a hash to a method. However, if you do so, the order in which you pass those parameters will become important.
For example :

#given the following method declaration :
def dance_like_an_idiot(normal_parameter1,normal_parameter2,params)
  puts(normal_parameter1)
  puts(normal_parameter2)
  puts(params[:frequency])
  puts(params[:idiocy_level])
  puts(params[:risk])
  #instructions to start the idiotic dance
end
#you could write :
dance_like_an_idiot("bleh","blah",:risk=>"be considered as a moron")
#but you couldn't write :
dance_like_an_idiot(:risk=>"getting beat down","bleh","blah")

Hashes do not replace arrays

Even though a hash is more flexible than an array, it must be noted that since the hash keys are not numerical values (FixNum instances), it cannot be ordered as easily. The other disadvantage is that it is less performant than arrays for the same reason. Still, ruby hashes are extremely useful. Most of the time you will prefer a hash to an array for the added flexibility.

In every single languages that I know the existence, every arithmetic, bitwise and conditional operators are built-in and global keywords. Well, once again, Ruby had to do things differently. You might be surprised to learn that most ruby operators are not built-in keywords. Fine you’ll tell me… but what are they then?

Instance methods

What? Yes. I’m afraid to tell you that Ruby is trying to fool you badly. The least we could say is that Ruby is a language who took the OO principles very seriously… in some kind of obsessive way (but we like it for this). Let’s look at it concretly :

def do_something_clever
  result = first_number + 18
end

Beware! Ruby is trying to make you believe that “+” is independent from “first_number” and “18”. Meeeeeeeep! (I just tried to reproduce the irratating sound that you hear on a quiz show when some guy gives a wrong answer. Although I admit it sounded more like the road runner on crack) The “+” sign is not a “sign” at all. It is an instance method of our object called “first_number”, which is a Fixnum. And what is 18? 18 is the parameter for the “+” method, of course!
We almost succeed to unmask ruby’s diabolical plans to fool our poor mind, so hold on. If “+” is an instance method of the Fixnum class, then where the hell is the dot between that so called method and our object? Well, that’s where the fooling occurs. For the sake of readability, Ruby lets you write an arithmetic expression the way you’re used to. Then, it does some magic behind the scene. It adds a dot, trims the spaces and somehow manage to transform the arithmetic expression in a standard object method call.
*** Update : Like JC pointed out, it also takes care of operator precedence. So when you write 5+8*5 in IRB (ruby interpreter accessible by command line), it correctly gets tranformed to 5.+((8).*(5)). Note that I don’t know exactly what kind of magic ruby does. I just know for sure that “magic happens somehow” ***
So :

result = first_number + 18

means the following to Ruby :

result = first_number.+(18)

If you really wanted to, you could very well write all your arithmetic expressions the way it is illustrated in the 2nd example, but then people would start hating you and soon you wouldn’t have any friend left. Is this what you want? I don’t think so. Still, I think it’s important to know what’s really happening behind the scene when you write an arithmetic expression.
The same holds true if you use numbers directly in your expression, that is, without storing them in some named objects. In fact, in these cases the name of the object is the number itself. This means that once again, you could have done : result = 5.+(3) and thus taking the unnecessary risk to lose all your friends while living a life of misfortune and pain. Again, that’s not what you want, so I suggest you stick with result = 5 + 3. This last paragraph has been edited on 03/31/2007, thanks to Gary Wright.
Finally, here is how the “+” method declaration looks like :

class Fixnum
  #some implementation
  def +(other)
    #some internal call I am unaware of that does the actual addition
  end
end

As simple as that. All of this gives some strength to the statement : “In ruby, everything is an object”, don’t you think?
#UPDATE 03/29/2007
Thanks to Joseph Wright who brought to my attention that the same thing was possible in smalltalk. I wasn’t aware.
[talking about smalltalk…]
When you define a method, it can either be infix (also called binary), which allows for e.g. ‘5 + 5′, where ‘+’ is the method; unary, which has just one argument, or keyword, which looks like ‘methodName Arg1: Arg2:’
[end quote]