> Lähettäjä: "David A. Black" <dblack@wobblini.net>
> Aihe: Re: Injecting methods from one class into another.
>
> Hi --
>
> On Wed, 26 Jan 2005, Sam Roberts wrote:
>
> > Quoteing dblack@wobblini.net, on Wed, Jan 26, 2005 at 09:31:29PM +0900:
> >> Hi --
> >>
> >> On Wed, 26 Jan 2005, E S wrote:
> >>
> >>> 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