------art_35619_13753260.1156247111622
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

> So I like to hear that short story:
>
> > The short of it is: two different classes of objects are
> > interchangeable if they both support the same (named) methods that code
> > using those objects invoke. You don't need static-typing or
> > compile-type checking. You don't need interfaces. You don't need
> > contracts. You just need to have the methods available that you are
> > going to call.
> >
>
> OK, if that's correct, then duck-typing is different from FPL's
> approach.


Strangely enough, C++ has something just like duck-typing.  They call a
duck-type a "concept":

http://www.sgi.com/tech/stl/stl_introduction.html
 Concepts and Modeling

One very important question to ask about any template function, not just
about STL algorithms, is what the set of types is that may correctly be
substituted for the formal template parameters. Clearly, for example, int*or
double* may be substituted for find's formal template parameter
InputIterator. Equally clearly, int or double may not: find uses the
expression *first, and the dereference operator makes no sense for an object
of type int or of type double. The basic answer, then, is that
findimplicitly defines a set of requirements on types, and that it may
be
instantiated with any type that satisfies those requirements. Whatever type
is substituted for InputIterator must provide certain operations: it must be
possible to compare two objects of that type for equality, it must be
possible to increment an object of that type, it must be possible to
dereference an object of that type to obtain the object that it points to,
and so on.

Find isn't the only STL algorithm that has such a set of requirements; the
arguments to for_each <http://www.sgi.com/tech/stl/for_each.html> and
count<http://www.sgi.com/tech/stl/count.html>,
and other algorithms, must satisfy the same requirements. 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.

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. Nevertheless, concepts are an extremely important part of the STL.
Using concepts makes it possible to write programs that cleanly separate
interface from implementation: the author of find only has to consider the
interface specified by the concept *Input Iterator*, rather than the
implementation of every possible type that conforms to that concept.
Similarly, if you want to use find, you need only to ensure that the
arguments you pass to it are models of *Input Iterator. *This is the reason
why find and reverse can be used with lists, vectors, C arrays, and many
other types: programming in terms of concepts, rather than in terms of
specific types, makes it possible to reuse software components and to
combine components together.

------art_35619_13753260.1156247111622--