From: "David A. Black" Date: 2005-01-27T02:18:11+09:00 Subject: Re: Injecting methods from one class into another. Hi -- On Thu, 27 Jan 2005, E S wrote: >>> However, if it responds to []= in a way that is NOT like a Hash responds >>> to those methods, it aint ducky type like a Hash. >> >> Do you mean how many arguments it takes? Beyond that, one object's >> behavior on being sent the []= message doesn't have to resemble >> another object's, from the point of view of type. The main thing is >> that they can both handle the message (including arguments). >> >> Actually this is an area where people have pointed to a potential >> limitation or even pitfall of duck typing: namely, coincidence of >> method name where there really is no common ground -- something like: >> >> dog.bark # ask dog object to bark >> tree.bark # retrive bark attribute of tree >> >> On the other hand, I'm not sure there have been any real-world reports >> of things like this causing problems. And a lot of duck typing ends >> up dealing with cases where at least loose conventional expectations >> apply (like [] and []= being index-ish, and << being append-ish). > > Here I must disagree: yes, Ruby's duck typing capabilities end here; > it can only check whether a given method is available, not if it takes > the given arguments or if it returns a suitable value, and that's > really fine. > > The concept of duck typing, however, should extend to both > assuming that the arguments given to a method are acceptable > (even if just discarded) and that its return value is suitable > for use by whomever sent the message. Borrowing the analogy again, > "If it walks like..." implies that the result of the message sent > is, indeed, the expected walking. It depends what you mean by "like" and "is". Consider this: a = [] b = "" a << "hi" b << "hi" In one case, the operation is "append to an array". In the other, it's "append to a string". At that level, these are different results -- but this is a classic case of duck typing. You could describe it more abstractly ("append to an object") -- indeed, you can get more and more abstract in your description of what the two objects do, until all you can really say is: "they <<". And that's where you started: asking them both to <<. To paraphrase McLuhan: for Ruby objects, the message is the message :-) David -- David A. Black dblack@wobblini.net