When to use self in Model?

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.

Solution 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.

Solution 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!

Solution 3:

It's to make sure you're using the setter method and not scoping a new variable. It's a Ruby and AR usage detail that often trips people up (the other being the (mis-)use of an instance variable).

Note there's already update_attributes! although I understand the desire to abstract.

There's also toggle!, which might be even nicer, depending on your interface to the flag.