Hal Fulton wrote:
>> "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.

I think of it like this:

The Image object manages the image buffer.  It should control what goes 
into the image and now.

The Text object manages a text string.  It controls what goes into the 
string, and provides various modes of access to the string.

To manipulate a string, the Text object needs *no* input from the Image 
object.  It's job is to manage a string.  That's all it does.

The Image object, however, needs to know about MANY different object 
types because it receives them as input for determine how to manipulate 
the image.  It manages an image buffer.  That's all it does.

 From that, I can only envision image.draw(text) as the most logical 
pattern.

	Sean O'Dell