Using self in Ruby comes naturally if you’ve been writing Ruby for any length of time. It’s easy to gloss over its meaning and significance, however.
Take, for instance, the following class.
class Car attr_accessor :make def initialize(make) @make = make end def blend_in(new_make) make = new_make end end
car = Car.new('Chevy') car.blend_in('Porsche') #=> "Porsche" car.make #=> "Chevy"
Why didn’t #blend_in work as expected? We missed a self. We should have written self.make = new_make.
It’s easy and sometimes tempting to memorize heuristics like “always use self. when calling a setter.” While rote memorization can help keep beginners from getting mired in the details, at some point it’s important to dig into the why.
Obviously if we leave off self., we’re assigning a local variable. But why does Ruby do this?
Ruby specifically tries to make setters look like regular variable assignments. In most cases, this makes Ruby very simple and elegant. It can also introduce ambiguity. Does make = new_make mean #make=(new_make) or does it mean ‘assign the value of new_make to a new local instance variable called make?’
There’s no way for Ruby to know. Did you notice I clarified the second case by writing it out in English? That’s because there’s no clearer, more unambiguous way to write it in Ruby. Because there’s no other way to write it, if Ruby defaulted to using a setter when one existed, there would be no way to define a local variable with the same name as a setter.
While it’s generally not good practice to do so, there are cases where it might be useful.
Using self in Ruby getters
So why don’t you need to use self. when calling a getter? In some cases, you do!
class Car attr_accessor :make def blend_in(new_make) make = new_make puts make puts self.make end end
car = Car.new car.make = "Chevy" car.blend_in("Jaguar") # prints "Jaguar" for make and "Chevy" for self.make