Robert Feldt wrote:

> Sean O'Dell <sean / cSePlsoAfMt.com[REMOVE_THE_SPAM]> skrev den Wed, 3 Sep 
> 2003 04:53:13 +0900:
> 
>> 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.
>>
> Although I agree with you on this one I'm not sure there will always
> be a clear-cut "most logical pattern". Thus I still think we should
> have a healthy debate about multi-methods in a potential future Ruby.
> But from previous ones I think matz doesn't like it; and maybe he is
> right. The additional complexity of implementation and learning
> may not be worth it since these situations are rare?

Object and method delineage will never be clear-cut, especially since 
the software patterns a developer is familiar will also play a role.

I think a healthy debate is fine, but the debate should not frivolously 
re-hash lessons already learned.

I trust Matz on this subject.

> To get a taste of the complexity check the description of the
> method dispatch in for example Slate:
> 
> http://slate.tunes.org/semantics.html

Delphi has a similar feature.  You can assign a method to any object.  I 
used it from time to time in the way I think some people use 
aspect-oriented programming.  It's a way to extend a living object in a 
way unknown to the original class author.  You could write a print 
method and slap it onto an image, or a string or whatever, and call 
string.print.  When reviewing the code for the object, the class code 
would show it doing one thing, but the method "plugged-in" at run-time 
would show another.  Sort of like how Ruby lets you append a singleton 
to a living object.

/shrug

	Sean O'Dell