When to use self in Model?

Question

Question: when do I need to use self in my models in Rails?

I have a set method in one of my models.

class SomeData < ActiveRecord::Base   def set_active_flag(val)     self.active_flag = val     self.save!   end end 

When I do this, everything works fine. However, when I do this:

class SomeData < ActiveRecord::Base   def set_active_flag(val)     active_flag = val     save!   end end 

The active_flag value doesn't change, rather it fails silently. Can someone explain?

I can't find any duplicates, but if someone finds one that's fine too.

Answer 1

When you're doing an action on the instance that's calling the method, you use self.

With this code

class SocialData < ActiveRecord::Base   def set_active_flag(val)     active_flag = val     save!   end end 

You are defining a brand new scoped local variable called active_flag, setting it to the passed in value, it's not associated with anything, so it's promptly thrown away when the method ends like it never existed.

self.active_flag = val 

However tells the instance to modify its own attribute called active_flag, instead of a brand new variable. That's why it works.

Answer 2

This happens because of scoping. When you're inside of a method and you try to set a new variable like this:

class SomeData < ActiveRecord::Base   def set_active_flag(val)     active_flag = val   end end 

You are creating a brand new variable that lives inside of set_active_flag. As soon as that's done executing, it goes away, not altering self.active_flag (the actual instance variable) in any way.

HOWEVER (this was a source of confusion for me): when you try to read an instance variable in ruby, like this:

class SomeData < ActiveRecord::Base   def whats_my_active_flag     puts active_flag   end end 

You'll actually get self.active_flag (the actual instance variable) returned.

---

Here's why:

Ruby will do what it can to avoid returning nil.

1. It initially asks "does active_flag exist within the scope of whats_my_active_flag?
2. It searches and realizes the answer is "nope", so it jumps up one level, to the instance of SomeData
3. It asks the same thing again: "does active_flag exist within this scope?
4. The answer is "yup" and so it says "I got something for ya" and it returns that!

However, if you define active_flag within the whats_my_active_flag, and then ask for it, it goes through the steps again:

1. It asks "does active_flag exist within the scope of whats_my_active_flag?
2. The answer is "yup", so it returns that value

In either case, it won't change the value of self.active_flag unless you explicitly tell it to.

An easy way to describe this behavior is "it doesn't want to disappoint you" and return nil -- so it does its best to find whatever it can.

At the same time, "it doesn't want to mess up data that you didn't intend to change" so it doesn't alter the instance variable itself.

Hope this helps!