I'm sometimes interested in "varying flavors" of OOP. The one
proposed here seems very extreme to me. It seems as though
a rigorous application of these principles would pretty much
rule out parameter passing, and the "single class" rule would
rule out inheritance. A full application of these ideas would
make it IMO nearly impossible to code at all.

[snip and move upward:]
 > Again, this is all just my opinion.  I hope I didn't come across as
 > insulting; if I did, I apologize in advance!
Likewise...

But that's not why I'm posting this. I have another opinion
question for all of you. See below.

> I guess I can explain how I see OOP something like this: the real world 
> is made up of objects.  You can describe OO programming in terms of 
> real-world examples.  I am an object.  I am made of other objects.  I 
> interact with other objects.  But I move through the world, and do 
> everything I do, procedurally.  I am an object which moves through life 
> procedurally.  I have my job, other objects have theirs.  Our places in 
> the world are clearly defined by "what I am" and "what I do."
> 
> So, in my line of thinking: me.eat(food)
> "Hello world".print to me equates to: food.eat.
> 
> I eat.  Food doesn't eat.  $stdout prints.  Strings don't print.

I like this example. It made me think of a discussion I was having a
few weeks back on when you design an interface like x.meth(y) and
when you do y.meth(x) instead.

The other person cited (I think) the _Design Patterns_ book, giving
polygon.draw(window) as an example. The polygon knows how to draw
itself, and you tell it where to do it.

Logical to many people, but feels backwards to me. I'd rather say
window.draw(polygon) on the theory that the window is where all the
drawing happens, and you tell it what to draw on itself, allowing
it to query the object-to-be-drawn as needed (since we're passing
it in).

Actually, I remember the concrete example now -- it was in RMagick.
To take a piece of text and stick it in an image, you do the
operation text.annotate(img) -- it was confusing to me, since I
wanted to do img.annotate(text) instead. FWIW, Tim Hunter ended up
adding the other way as an alternative. :)

I've just realized that in the back of my mind, I prefer passing
the "little object" into the "big object" rather than vice versa.
Hmm. A psychological aspect there.

Much of what Ruby already does bears this out, I think.

    array << item       # not item << array
    stack.push(item)    # not item.push(stack)
    queue.add(item)     # not item.add(queue)

Junk-food for thought...

Hal