self in Ruby

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.

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!

 

About Alexander

Alexander has been programming for a very long time. When he met Ruby, it was love at first sight.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *