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...
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...
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)'. The `attr=' 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 variable `attr' 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
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.
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...
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.
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.
···
On 4/2/06, Fred <0bssel602@sneakemail.com> wrote:
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...
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.