[1]
class C
attr_accessor :a
def f(v) @a = v
...
end
end
[2]
class C
attr_accessor :a
def f(v)
a = v
...
end
end
[1] and [2] work exactly same.
I wonder which way is more proper.
In my opinion, if there're accessors (getter and setter), using them in
the class is better than directly accessing the instance data.
However, most codes I've seen access the data directly.
In my opinion, if there're accessors (getter and setter), using them in
the class is better than directly accessing the instance data.
However, most codes I've seen access the data directly.
What do you think?
I tend to agree. It's more flexible if you later need to redefine the accessors to do some extra computation or store the value differently.
···
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
[1]
class C
attr_accessor :a
def f(v) @a = v
...
end
end
[2]
class C
attr_accessor :a
def f(v)
a = v
...
end
end
[1] and [2] work exactly same.
I wonder which way is more proper.
In my opinion, if there're accessors (getter and setter), using them in
the class is better than directly accessing the instance data.
However, most codes I've seen access the data directly.
What do you think?
Sam
Hi Sam,
Just a quick point: your examples don't work the same way. In [2], you'll want to replace a = v with self.a = v.
In my opinion, if there're accessors (getter and setter), using them in
the class is better than directly accessing the instance data.
However, most codes I've seen access the data directly.
Another advantage of using accessor methods (self.foo = ) over variables (@foo =) is that it can help avoid typo bugs. Variables are initialised to nil, so if you write @the_variable in one place and later elsewhere read @thevariable, you don't get an immediate complaint. If you typo an accessor method, you get an immediate NoMethodError .
I've moved to this style over time - also because it's easier (I find) to do things using method reflection - eg adding and notifying observers.