Joel VanderWerf <vjoel / PATH.Berkeley.EDU> writes:

> Lloyd Zusman wrote:
>
>> Duck typing cannot work unless methods with the same names and
>> signatures behave in the same way in the various classes that implement
>> them.  If the ability to do duck typing is deemed to be an important and
>> necessary feature of an object-oriented language, then the standard
>> libraries that are written for that language _must_ provide different
>> names and/or signatures for methods that perform different functions.
>
> But "same" and "different" are on a continuum. Sometimes Array#[] and
> Hash#[] are close enough that sharing their method name makes sense
> (e.g., using hashes as sparse arrays).

Yes, sometimes. Recall the statement in my original post where I said
that duck typing can indeed work in Ruby in _some_ cases ... but not
all.


>> Since [] and []= have certain semantics for one set of classes
>> (array-like classes) and different semantics for other classes
>> (hash-like classes), then we must conclude that Ruby was not designed
>> with the duck typing in mind.
>
> [] and []= don't even have the same semantics from hash to hash, because
> of default_procs, singletons, etc. An object may respond to all the
> usual Hash methods, and the object may be a Hash in the sense of
> obj.is_a?(Hash), but it still doesn't behave as expected.
>
> Of course, this may be an extreme example that is irrelevant to a given
> application. But it reinforces the point that it's really hard to encode
> semantics within interface, in any language. Hence unit tests.

Although unit testing is, in my opinion, necessary and very helpful, it
does not operate in the same "space" as duck typing.

The way I understand it, duck typing is used at run time to decide how
to operate on a given object.  Here's one example out of many:

If an object that is encountered within a given program is thought to be
something hash-like, that program might want to perform one set of
functions on the object; if that object is thought to be string-like,
perhaps a completely different set of functions might be performed on
it; etc.  With a universe of classes that are well defined in certain
ways, duck typing can be used to achieve this end.

Unit testing, on the other hand, is not done at run time to determine
how to process a given object that is encountered in the program;
rather, it's used in order to help ensure that a program behaves
correctly given any and all inputs that it might be given.

Comparing unit testing to duck typing is, therefore, analogous to
comparing apples to oranges.



-- 
 Lloyd Zusman
 ljz / asfast.com
 God bless you.