----- Original Message -----
From: "Charles Hixson" <charleshixsn / earthlink.net>


> Tom Sawyer wrote:
> >
> >i'd like to refocus on this aspect of the ambiguity thread. from what's
> >been posted thus far on the topic, it would seem it is best to always
> >use the accessor methods when they exist. i hanker to bet many of us do
> >not do this. and i think this has to do with the fact that the
> >...
>
> It has been asserted.  I don't think that it has been generally agreed.
>  Within a class accessor values may be either used or not used depending
> on why they were created, and what the cost of using them is.  Partially
> also on how large the class is, whether the change is being made as a
> part of the same declaration that was the original class declaration, etc.

Charles's points are sensible.  My own experience is that I *hardly ever*
create "setter methods", only attr_reader methods.  This is because my objects
should be changed in ways reflect the grand plan of the object, rather than the
whim of the object's user in wanting to set some field.  And since I don't
allow the object user to set individual fields, the "@field = value" syntax has
all the convenience without the compromise.

My point is that explicit setter methods can be philosiphized out of existence,
thus rendering the whole "self.field = value" debate academic.  To borrow a
phrase from the PickAxe: attr_writer is one of those ideas that looks essential
on paper but isn't used much in practice.

Of course, that's just me, and while I think my approach is good, it's limited
to the kinds of problems I solve, which tend to be nice and small.  Thus I
conjecture a second point.

The syntax (for "setter methods") "object.field = value" implies simplicity.
If you need to jump through various hoops every time a field is written, you
probably want a method that implies it does something serious.  Saying
something simple while doing something complicated will likely make code hard
to read.  A minor point, perhaps, but one which, if followed, could again take
the sting out of the writer-method-withoud-explicit-self ambiguity.

In short, Ruby offers so many nice features, paradigms, and ease-of-use that
I'm happy to rearrange my "way of doing things" a little to make the code flow
more easily.

> [snip some more good arguments]

> -- Charles Hixson

--Gavin