Self.some_attribute vs @some_attribute

Hello,

I just finished reading the Agile book. Of course I forgot at least the
two thirds of what I read. I started reading the source code of Typo, to
see a real (and Rails) application.

I stumbled upon this snippet of code:

def crypt_unless_empty
if password(true).empty?
user = self.class.find(self.id)
self.password = user.password
else
write_attribute “password”, self.class.sha1(password(true))
@password = nil
end
end

is there any practical reason to use sometimes self.password and
sometimes @password? I thought they were synonyms…

Fred wrote:

  user = self.class.find(self.id)
  self.password = user.password
else
  write_attribute "password", self.class.sha1(password(true))
  @password = nil
end

end

is there any practical reason to use sometimes self.password and
sometimes @password? I thought they were synonyms…

The difference between self.attr = val' and@attr = val’ is simply
that the first is a method call, i.e. the same as self.attr=(val)'. Theattr=’ method may check the value, and do a lot of different things -
when you use @attr = val', the only thing happening is that you assign the instance variableattr’ the value of `val’. Take this, for
instance:

class User
attr_reader :name

 def initialize(name)
   # @name will be a string
   self.name = name
 end

 def name=(val)
   # make sure @name is a string
   @name = val.to_str
 end

end

Cheers,
Daniel

Fred wrote:

is there any practical reason to use sometimes self.password and
sometimes @password? I thought they were synonyms…

@password refers to an instance variable.

self.password refers to a method named ‘password’, which may or may not
have anything to do with any instance variables.

People will often use methods to get and set instance variable values to
allow for code that checks values, handles business logic, and so on.

But methods and instance variables are not coupled, and one shouldn’t
assume that any given method is interacting with an instance variable of
the same name.


James B.

http://web2.0validator.com - We’re the Dot in Web 2.0
http://refreshingcities.org - Design, technology, usability
http://yourelevatorpitch.com - Finding Business Focus
http://www.jamesbritt.com - Playing with Better Toys

Fred wrote:

is there any practical reason to use sometimes self.password and
sometimes @password? I thought they were synonyms…

self.password = … # calls the method “password=”

It’s a method call. You might assume from the name it sets @password,
but it may do other stuff as well (e.g. checks, or in this case, encrypt
the given password string).

In an ActiveRecord subclass (as this appears to be) password=(foo) is a
method that just calls write_attribute(“password”, foo), simply setting
the password attribute of the active record. There’s no @password
involved, only @attributes[“password”].

Of course, this method can be overridden, and it probably is in the
class you’re looking at. Look for the line beginning “def password=” for
more clues.

Cheers,
Dave

On 4/2/06, Fred [email protected] wrote:

  user = self.class.find(self.id)
  self.password = user.password
else
  write_attribute "password", self.class.sha1(password(true))
  @password = nil
end

end

is there any practical reason to use sometimes self.password and
sometimes @password? I thought they were synonyms…

Rails is a bit different in this scenario than most other Ruby programs.
The attributes in your model classes that are picked up at runtime
from your database schema are not defined as regular methods.
@blah = ‘something’ will not necessarily do what you expect to the
value in the ‘blah’ column of your table.
If you’re using an accessor you defined yourself, self.something and
@something are equivalent. If you’re using an ActiveRecord attribute,
you should exclusively use self.something or self[:something].

–Wilson.

Rails is a bit different in this scenario than most other Ruby programs.
The attributes in your model classes that are picked up at runtime
from your database schema are not defined as regular methods.
@blah = ‘something’ will not necessarily do what you expect to the
value in the ‘blah’ column of your table.
Indeed, I just noticed this.

In that case, it appears the instance variable is used to do some
manipulations I still need to understand before writing the crypted
value to the database.

Thanks