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