Injecting methods from one class into another

ruby-talk
1

Lähettäjä: "David A. Black" <dblack@wobblini.net>
Aihe: Re: Injecting methods from one class into another.

Hi --

> Quoteing dblack@wobblini.net, on Wed, Jan 26, 2005 at 09:31:29PM +0900:
>> Hi --
>>
>>
>>> Duck typing, essentially, means that, /in a particular context/, a
>>> given object has all the characteristics of a given type. For example,
>>> it might be enough for an object to implement and = for it to be
>>> treated as a Hash in a certain context.
>>
>> It's not exactly that it's being treated as a Hash -- it's more that,
>> *like* a Hash, it's being treated as an object that responds to and
>> =. This is, perhaps, a subtle point, but I think it's key in
>> getting away from the class-based view. All of the /= objects
>> converge on the type that can only be described as "the type of
>> objects that respond to and =". In that sense, Hashes are just
>> one of infinitely many possible objects that exhibit the behaviors of
>> that type.

I concur, that's a better way of saying it.

> I see your point.
>
> 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.

David

E

···

On Wed, 26 Jan 2005, Sam Roberts wrote:
>> On Wed, 26 Jan 2005, E S wrote:

2

Hi --

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
:slight_smile:

David

···

On Thu, 27 Jan 2005, E S wrote:

--
David A. Black
dblack@wobblini.net