Why am I able to call the class method as if it were an instance method here? - sql

Question

I was looking through this example:
class SQLObject
def self.columns
return #columns if #columns
columns = DBConnection.execute2(<<-SQL).first
SELECT
"#{table_name}".*
FROM
"#{table_name}"
LIMIT
0
SQL
columns.map!(&:to_sym)
#columns = columns
end
def self.table_name
#table_name ||= self.name.underscore.pluralize
end
def insert
column_symbols = self.class.columns.drop(1)
column_names = column_symbols.map(&:to_s).join(", ")
question_marks = (['?'] * column_symbols.count).join(", ")
DBConnection.execute(<<-SQL, *attribute_values)
INSERT INTO
#{self.class.table_name} (#{column_names})
VALUES
(#{question_marks})
SQL
self.id = DBConnection.last_insert_row_id
end
end
And I was confused as to why it's ok to call the table_name method in the "self.columns" method as if it were an instance method. Isn't the "table_name" method a class method? Hence, shouldn't it be called as "self.class.table_name" in the "self.columns" method as well?

Answer 1

When inside an abstract class, the self refers to the proper class, not the object. That's why you can access the method without explicitly telling self

Answer 2

Short answer: self is the implicit receiver in Ruby. If you leave it out, the message will be sent to self. In other words, it is never necessary to say self.foo in a message send, because foo is always implicitly the same as self.foo.
Long answer: there is no such thing as a "class method" in Ruby. What you call a "class method" is actually nothing but a singleton method defined on an object which just happens to be an instance of the class Class.
Actually, there are no singleton methods in Ruby, either. A singleton method is really nothing but a regular old instance method which is defined on the singleton class of an object.
[Note: This is not to say that you should not use those terms. Saying "class method" is clearly simpler and communicates intent better than "instance method of the singleton class of an object of class Class". Also, note that there are methods such as Object#singleton_methods. Those terms clearly exist in the Ruby Community, but it is important to understand that these concepts do not exist in the Ruby Language. They are a tool for communication, not an actual Ruby concept.]
The singleton class is a class that is associated with an individual object. Each object has exactly one singleton class and that object is the only instance (the "singleton instance", hence the name) of its singleton class.
In fact, the inheritance hierarchy of an object always starts with its singleton class, i.e. the class pointer of an object always points to its singleton class, and the singleton class's superclass pointer then points to the class that created this object. You just don't see the singleton class in the inheritance chain, because methods like Object#class "skip over" the singleton class when calculating the inheritance chain. It is, however, always used during method lookup.
In fact, method lookup is actually very simple (the only exception is Module#prepend, which I am going to ignore for this explanation):
Dereference the receiver's class pointer.
If that class's method table has a method by the name of the message, invoke it. STOP.
If not, dereference the class's superclass pointer.
GOTO #2.
If you reach a class that doesn't have a superclass, restart the algorithm with the message method_missing(original_message_name, ...), unless the message name is already method_missing, in which case raise a NoMethodError.
So, it all comes down to two questions:
When defining a method, which class (or module) are you defining it in?
When sending a message, which object are you sending the message to?
When you define a method using def foo.bar, Ruby will first evaluate the expression foo and then define a method bar on the resulting object's singleton class (the definee). If you don't provide foo, i.e. you just say def bar, then bar is defined on the default definee, which is a little bit of a tricky concept. Normally, it is the closest lexically enclosing module definition. If there is no enclosing module definition, i.e. you are at the top-level, the default definee is Object and the method visibility is private.
When you send a message using foo.bar, Ruby will first evaluate the expression foo and then send the message bar to the resulting object (the receiver). If you don't provide foo, i.e. if you just say bar, then the default receiver is self.
Which brings us to the next question:
What is self?
Within a method definition body, self is the receiver of the message send that led to the invocation of this method. So, if you send the message foo.bar, then any reference to self in the definition of the method bar will, during this one execution of the method, evaluate to foo.
Within a module or class definition body, self is the class or method itself. (That is why defining a singleton method instance method of the singleton class using def self.bar works in a module or class definition body.)
Within a block or lambda literal, self is lexically captured, i.e. it is whatever self is at the point where the block or lambda literal is written. However, there are a couple of methods which change how self is evaluated, most notably the BasicObject#instance_eval, BasicObject#instance_exec, Module#module_eval, Module#module_exec, Module#class_eval, Module#class_exec, … family of methods.
If you are always aware of the answers to those three questions (where am I defining a method, what is the receiver of a method call, what is self) at any point in your code, then you have basically understood the most important parts of Ruby.
So, to put it all together:
At the point where you are defining the method using def self.columns, we are in a class definition body, so self refers to the class object itself (SQLObject).
The syntax def foo.bar defines a method bar on the singleton class of foo. In this case, you define the method columns on the singleton class of SQLObject. This means that the object SQLObject is the only object in the universe that will respond to the message columns.
Both of these also apply to the definition of self.table_name.
Inside of the method body of self.columns, self will dynamically refer to whatever the receiver is.
When you send the message columns to SQLObject, i.e. you write SQLObject.columns, then inside the body of the SQLObject::columns method, the receiver (i.e. self) will be set to SQLObject. (In this case, the receiver will always be SQLObject, since this is a method of a singleton class.)
So, inside the method body of self.columns, when you write the message send table_name, this is a message send with an implicit receiver. Since the implicit receiver is self, this is equivalent to self.table_name. self at this point is bound to SQLObject, so this is equivalent to SQLObject.table_name. In other words, the message is sent to SQLObject.
Now, per the algorithm I outlined above, the method lookup first retrieves the class pointer from SQLObject. As mentioned, the class pointer always points to the singleton class. So, we look inside the singleton class of SQLObject to see if we find a method named table_name, and we do!
Method lookup is finished, everything works.