From: E S <eero.saynatkari@...>
Date: 2005-01-27T00:32:09+09:00
Subject: Re: Injecting methods from one class into another.

> L�hett�j�: "George  Moschovitis" <george.moschovitis@gmail.com>
> Aihe: Re: Injecting methods from one class into another.
> 
> > If the only requirement one has of a duck is the ability to fly, then
> for
> > all intents and purposes, a hawk is a duck.
> 
> Thats my point :)
> 
> > Signor Moschovitis, however, was essentially claiming that since a
> hawk can
> > fly and a duck can fly, a hawk must be a duck (or, if an object
> responds to
> > of the methods of a given type, it should somehow be able to respond
> to all > the > others as well).
> 
> never claimed that , I only want to 'inject' the one method from Duck
> that is compatible with Hawk. Read my example more carefully please.

It was an oversimplification, apologies. Addressing the exact code, I
would say that even if an object has a certain characteristic (@a or,
say, wings) doesn't mean it can be used the same way another object 
uses it (be it a= or flying in the case of e.g. a penguin). That's a stretch, though. Duck typing should not take into account the 
/internal/ state of an object, just its interface. 

Injecting methods just doesn't seem to be right and I think the proper 
answer would be to factor out any such common code rather than 
forcibly extract it. For example, the [] and []= methods could be 
implemented by Indexable (although the differences in parameters and 
output would not allow those particular methods to be factored out, 
probably).

> -g.

E