From: Matthew Johnson <musical.matthew@...>
Date: 2006-08-22T22:13:21+09:00
Subject: Re: so called "duck typing" vs. FP (Re: Strategy pattern / interface design arrangement)

> These requirements are sufficiently important that we give them a  
> name: we call such a set of type requirements a *concept*, and we  
> call this particular concept *Input
> Iterator <http://www.sgi.com/tech/stl/InputIterator.html>*. We say  
> that a
> type *conforms to a concept*, or that it *is a model of a concept*,  
> if it
> satisfies all of those requirements. We say that int* is a model of  
> *Input
> Iterator* because int* provides all of the operations that are  
> specified by
> the *Input Iterator* requirements.

There is a lot of power in identifying a cohesive set of type  
requirements and giving them a name as it allows communication and  
thought to move up a level so we can think of the requirements as a  
single entity rather than thinking repsonds_to? :this and  
responds_to? :that.  This is much the same as using iterators rather  
than explicit loops in our code.

A group of type requirements that is cohesive and is given a name  
also increases the likelihood that code from various sources will be  
written that both conforms to and works with types conforming to the  
requirements.  A nice example of this is the large number of types in  
Ruby which work with Enumerable by implementing each and possibly  
having members that implement <=>.

I believe it would be of benefit to the Ruby community to name more  
of these cohesive sets of type requirements and give them informal  
definitions as they are identified.  STL provides examples of many  
sets of type requirements, although STL concepts do not fit the Ruby  
Way very well at all and of course would need to change quite  
significantly in order to feel natural in Ruby.  The collection  
concepts and function object concepts in particular are very well  
thought out and could be very applicable in more clearly defining  
some common "duck types" in Ruby.

> Concepts are not a part of the C++ language; there is no way to  
> declare a
> concept in a program, or to declare that a particular type is a  
> model of a
> concept.

Although interestingly they are likely to be a part of the language  
in the future.  There are a variety of Technical Reports published  
that are being considered by the standards committee, thus  
illustrating how the C++ approach is different from Ruby as there is  
a strong desire in the C++ community to remove the freedom and find a  
way to statically check duck types.

Matthew