This is a loaded topic, so I thought I would start with the fundamentals and talk about what objects are exactly in these two languages.
is the same as:
1 2 3
which is the same as:
1 2 3 4 5
Note the familiar
() syntax after the function call: this means execute me like I’m a function. If you leave that out, you return the function
as if you’re calling the name property shown above.
As you can see, JS objects appear like simple dictionaries, a repository of properties that reference other objects and you can access these properties directly on the object. As a side note, various JS engines do not necessarily implement objects as hash tables under the hood. Check out the way V8 implements property access.
What are Ruby objects?
Where a JS object is a collection of properties that reference other objects, a ruby object contains a hash of instance variables that reference other objects. You can not access these instance variables in the same way that you can access (read or write to) JS properties. Ruby enforces a level of data encapsulation which protects these variables. Only when you are within the context of an object, which occurs during a method call, you can create or alter instance variables.
1 2 3 4 5 6 7 8
Before we talk about the instance variable
@var, it’s a good time to discuss the
Simple class above, because Ruby objects can not exist without classes.
A (very) brief intro to Ruby classes
Ruby is a class based language, whereas JS is not (although you can achieve level of class like behaviour). In Ruby, every object has an associated class:
1 2 3 4
You could say that the JS equivalent to this method is the
__proto__ property, even though this represents the prototype object from which the JS object was created.
This will be discussed in the length in part two.
Ruby classes are a place to define methods, which give objects their behaviour:
Notice that the methods returned above are defined in our Simple class. These are the proverbial getters and setters that are familiar if you have used Java or C#. They provide
access to the
@var instance variable that we can not access otherwise. In Ruby, we can simplify the Simple class code by calling the class method
attr_accessor to define these
getters and setters for us:
1 2 3
If you repeat the
instance_methods call on our new implementation:
the results are the same as the original implementation.
attr_accessor wrote these methods for us. This is a little bit of metaprogramming magic (which we will talk about in a future part).
In JS, there would be no need to create functions to do this, since properties on JS objects are publicly accessible.
In Ruby, classes (like almost everything) are objects and so we can call methods directly on them:
1 2 3 4
Notice that the class of Simple is Class. If you peek at the instance methods of Class:
you will find the
new method. This method is the mechanism to create a new object (covered in part two).
Classes are responsible for a lot of magic in Ruby, and we will cover Ruby classes extensively in future parts.
So getting back to the
@var instance variable. In the sample above,
@var is accessible through the getters and setters:
1 2 3 4 5
Note that this appears similar to JS access to properties, but in fact,
var is a method call on
simple_obj, which is the method receiver. In the JS equivalent, var would be a property, not a method (function) call.
The @ notation basically means: access this instance variable in the scope of the current context.
The current context is the object referenced by
simple_obj. The current context is an important concept in both JS and Ruby (which is where the
self keywords come into play),
and we will cover this in part two when we look at object creation.
Remember when I said that instance variables are private to the object? Well this is not quite true. Ruby gives you a lot of power and has some interesting methods that allow you to peek inside the object:
1 2 3
At this point, no instance variables have been assigned to the object.
1 2 3
@var is assigned, see it in the second call.
At their very core objects in JS and Ruby are simply repositories of references to other objects.
The essential difference is that JS does not restrict access to properties. The language itself does not support any data encapsulation on objects directly. That does not mean you can not achieve this in other ways however through function scopes acting as modules.
Ruby on the other hand enforces a certain level of data encapsulation by not providing a simple way to access its internal instance variables. You have to enter the object’s context through a method call to operate on instance variables. However, we just demonstrated above that there are methods that allow you to peek into, change or get individual instance variables which break this data encapsulation.
Ruby objects are more involved since objects contain a reference to the class that created it. The object relies heavily on this relationship throughout its lifetime, since whenever a method is called, the object refers to its class (and potentially ancestor classes) to find and execute the method. Classes (and it’s parent class, Module) are what make metaprogramming possible.
There is obviously a lot more to the object models of both languages, so I hope you will tune in to part two when I look at how objects are created in both languages.