Hi,
I was wondering what methods ending in an equal sign meant, but am not
sure what to search for? Could anyone point me to any resources or tell
me some terms to search for.
Thanks!
-Greg
Greg Christopher wrote:
Hi,
I was wondering what methods ending in an equal sign meant, but am not
sure what to search for? Could anyone point me to any resources or tell
me some terms to search for.Thanks!
-Greg
It’s sugar syntax!
So the method assign=(user_id), can be written in ruby: @object.assign =
user_id
Note the spaces around the equal sign 
Got it - maybe. I found a good resource[1], but I am not sure I
understand the value of the setter method in the first place. It would
seem that benefit is being able to skip explicitly calling save on an
object. Is that right?
If I had this method defined on my class:
def my_attribute=(some_value)
@some_value = some_value
end
I could call:
@object.my_attribute = new_value
instead of:
@object.my_attribute = new_value
@object.save
Is that the reason to define a setter method?
On Sat, Sep 26, 2009 at 8:38 PM, Mario Gr
[email protected] wrote:
Got it - maybe. I found a good resource[1], but I am not sure I
understand the value of the setter method in the first place. It would
seem that benefit is being able to skip explicitly calling save on an
object. Is that right?
The benefit of getter and setter methods are many - essentially they
allow you to perform operations on the variable before and after they
are retrieved or set. This is part of object-oriented methodology. But
in reference to your first question - “I was wondering what methods
ending in an equal sign meant”, it is a feature of Ruby itself that
methods can end in “!”, “?” and “=”, and the community has taken these
to mean “potentially dangerous/exception creating”, “interrogative
(should return a boolean)” and “sets a variable”, respectively.
instead of:
@object.my_attribute = new_value
@object.saveIs that the reason to define a setter method?
No, because in #my_attribute=, you did not call save. Here is a reason
to define a setter method:
class Shape
def save_intersection=(shape)
@intersection = self.calculate_intersection(shape)
end
end
That is, we need to calculate the intersection of these two shapes and
then we can store the result in an instance variable. This is a good
use of the setter syntax, because it sets a variable, and we need to
do something “special”. However, if we’re not doing anything special
with the variable being set, it is preferable to write:
class Shape
attr_accessor :points
end
Which automatically defines the methods #points, which gets the
instance variable @points, and #points=, which will set the instance
variable if you used it like:
shape = Shape.new
shape.points = [1.2, 3,3]
Colin
On Sat, Sep 26, 2009 at 9:31 PM, Colin C. [email protected]
wrote:
in reference to your first question - "I was wondering what methods
Er, I mean, if that was you also. I forgot to check the original
poster’s name. 
Colin
Yeah, i was using my buddy’s computer.
So, I think I understand, but want to make sure I understand how I would
use these practically. Basically, using these ruby shortcuts allows me
to better work with and manage variables that I won’t immediately be
saving with my object.
For instance, in your special case, if I need to calculate the
intersection of two shapes for the view, but didn’t need to save that
value in my DB, then I would use the setter method?
Maybe in your second example, where I’m doing nothing special, but had
these points, I’d be using those points in a view or some other output,
but wouldn’t be returning them to be stored on a record, at least not
immediately. Yes?
Thanks!
-Greg
Greg Christopher wrote:
Yeah, i was using my buddy’s computer.
So, I think I understand, but want to make sure I understand how I would
use these practically. Basically, using these ruby shortcuts allows me
to better work with and manage variables that I won’t immediately be
saving with my object.
At this point, you should probably read Programming Ruby (or a similar
book) and get a good understanding of accessor methods. There’s little
or nothing Rails-specific in this discussion, and we are far enough
toward the “Ruby basics” end of the spectrum that it will be a better
use of everyone’s time and brain power if you come back after you do a
bit of reading.
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]