From: "Bill Kelly" <billk / cts.com>
> 
> From: "James Britt (rubydev)" <james / rubyxml.com>
> > 
> > > 
> > > That is, Ruby lets us start out with an attr_accessor for
> > > :num_monkeys in class Barrel, just getting and setting a 
> > > stored value; but if computation should become necessary to
> > > the task, Ruby lets us define Barrel#num_monkeys and
> > > Barrel#num_monkeys= as methods more complex than those auto-
> > > generated by attr_accessor. . .
> > > 
> > > . . . Does this address any of your concerns, or am I, like,
> > > totally missing the point?  =)
> > > 
> > 
> > I think the issue (possbly raised by Holub) is that, regardless of how
> > the getter derives the return value, the client becomes dependant on
> > that value type.  So, if num_monkeys really should return a complex number
> > rather than an integer, client code breaks when that's changed.
> 
> Hmm, Interesting . . . . . . .
> 
> > A question to ask is, why is some code asking an object for data?
> > Wht can't the code tell the object to proces its own data internally?
> 
> This assumes nothing has a return value?  Of any kind ?? ?

[my rambling snipped]

Okay, in thinking a bit more about this, I think I'm fretting 
over a distinction between classes whose main function in life
may be to compute some kind of value or answer based on the
data they hold, and classes which, in accordance with Demeter
and Tell, Don't Ask, can just be told to do something useful
with the data they (ostensibly) hold internally.

I am indeed familiar with the horrors of "getters & setters"
out of control. . . I myself write perfect code, of course. ;)
And have been a fan of Demeter and Tell, Don't Ask, before I
knew the names of these practices (that part's pretty much
true.) . . . And maybe, glancing back up at the subject <grin>
which seems to mention UI's, if we (read: I) restrict the
discussion to just classes for which there is an associated
user interface, maybe such classes can nearly always be the
Tell, Don't Ask kind, rather than the compute a value kind.(?)

Just for fun, although this is getting way off-topic for Ruby,
I'd like to present a Java method, part of a user interface
component of a legacy codebase we inherited on the last 
project.

public ISFindToolsPanel getFindToolsPanel ()
{
    ISFindToolsPanel aISFindToolsPanel = null;
    DictionaryManager aDictMgr = getDictionaryManager();
    if (aDictMgr != null) 
    {        
        if (aDictMgr.getISFrame() != null)
            if (aDictMgr.getISFrame().getISTabbedPane() != null)
                if (aDictMgr.getISFrame().getISTabbedPane().getSearchTabPanel() != null)
                    if (aDictMgr.getISFrame().getISTabbedPane().getSearchTabPanel().getFindToolsPanel() != null)
                        aISFindToolsPanel = aDictMgr.getISFrame().getISTabbedPane().getSearchTabPanel().getFindToolsPanel();
    }
    return aISFindToolsPanel;
}

. . . indeed, the very poster child for Demeter.  Amazingly the
whole codebase was riddled with method after method like this.
The whole thing was one giant getter & setter (and they could
all return null).

So, yeah, in summary I wholeheartedly agree with avoiding 
getters & setters at all costs unless they are the "value-
computing" kind that are part of the function of the class
itself. . . . Which brings us back to Barrel#num_monkeys.
My thought was that num_monkeys might be a desirable 
question to ask of a Barrel, just like num_items might be
a reasonable question to ask of a (say) UI scrolling list
container. . . (?)

Anyway I hope that's a better, er, makes more sense than my
previous rambling . . . I'll just clamber back into my Barrel
now. =)

Regards,

Bill