Hi --

On Sun, 3 Dec 2006, paul wrote:

> :) thanks all for the educating responses. Martin, I really liked you
> suggestion.
>
> Let me explain the reason why I did want to chain assignments:
> I have a class that has a lot of attributes that can be written at
> creation of an instance. To save my typing the whole lot I made a
> constructor getting all those attributes. Though, I expect a lot more
> attributes in the near future. Since the attributes are not mandatory
> for creating the instance using the constructor-method seemed a little
> rigid.
> My second idea was to use attr_writer to set all the properties, but
> chaining seemed saving me some lines (these assignments aren't that
> exciting after all).
>
> Is there any moral/principal reason to write:
>  A.a = "AA"
>  A.b = "BB"
> instead of:
>  A.set_b("BB").set_a("AA")

I guess my question would be: why invent a new way to assign to
instance variables, when Ruby already has a nice way to do that?
Also, I tend to read set_b("BB") as returning "BB".  And understanding
it, at the very least, requires knowing about your set_attr method,
which adds another unnecessary layer.

It's not that I think, "Wow, that's elegant!" every time I see an
assignment.  They sort of fade into the background.  But a new way of
doing them, unless it's really adding value, does draw attention to
itself, largely of a negative kind I would expect.

(I agree with Martin that that's about the best you're going to do if
you feel you have to chain these things, but I'd counsel against the
chaining.)


David

-- 
                   David A. Black | dblack / wobblini.net
Author of "Ruby for Rails"   [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog)        [2] | Co-director, Ruby Central, Inc.   [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com    | [4] http://www.rubycentral.org