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 ?? ?

Still  ..  . . . thinking about this. . . 

main() {
  // do something
  // . . .
  // return some differentiable code to calling prog
}


. . . So, somebody has to return something, sometime ??

. . . It just seems strange - I'm not trying to be dismissive.

It just seems strange that nothing is allowed to return anything
for fear that something might not . . . be . . . known to be
guaranteed the same type in the future. . . . COM handles that
(I understand) by defining interfaces that don't change (but
which new interfaces are allowed to improve on . . . (upon?:))

. . . So, . . . . . is it a "given" that some classes/methods
need to return some kinda . . . kind of values, or . . . ?
Is there truly some kind of hierarchical new-approach wherein
nothing never needs to return a value to anything?  (...Sorry.
I suspect I'm being silly ;=)

> (What's refered to as "Tell, Don't Ask" by the Prag Prg folks, I believe)

I am in pretty much total agreement with this, . . . I think.
I've written systems which were . . . . . . pretty much isolated
from their callers' . . . . . .  . . I wonder if the whole thing
followed this principle or not?  Hmm . . . Yeah, I'm in favor of
Tell, Don't Ask, but . . . Hmm. . . . yeah in the system in 
question, the "telling" was done from .  .  . . .
So, we "told each other" in a sense: 'they' told me what they
needed in terms of set-up parameters, and 'I' told them what
had occurred in terms of user-response. . . . . It was a feedback-
loop. . . .  Kind of cyclic(-seeming) .. . But . . . Aaaughhh!!!

I . . . . . see, some things, you Ask, and they Tell.  Or, you,
"Tell" and they, . . . respond? ? ?

There were definitely things in that system - what is a 
function f(x) after all . . .?? . . . Are we allowed to 'tell'
it only?  It's an Ask_+_Tell relationship combined.

Maybe I'm missing something =)   . . . So, I'm gonna leave this
now, 'cause I think I've talked about all the variations I can
currently see - and I'm sure I'm missing something. :)

> I certainly wouldn't *ban* getters & setters, but trying to avoid them has
> help me produce less-coupled code.
> 
> 
> James


Regards,

Bill