When to use self in Model?

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

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.

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  endend

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  endend

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!

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.