[Python-3000] Kill "generic functions"!

[Guido van Rossum]

On 4/6/06, Aahz <aahz at pythoncraft.com> wrote:
> I cringe every time I see the phrase "generic function".  It's way too
> generic -- it doesn't contain any hint of its meaning, and I find it
> confusing because Python already has what I think of as generic
> functions:
>
> def adder(a, b):
>     return a+b
>
> That's a perfectly good generic function that depends on Python's
> duck-typing.

No, the term for this is polymorphism.

I don't like "generic" either though, because e.g. in Java (and C++?)
the term "generics" is associated with parameterized types a la
Collection<String>.

> "Multimethods" works, but Python is in many ways
> function-oriented rather than method-oriented.

It's also confusing because these things don't directly relate to the
methods we already have. (There's a way to view it differently, of
course, but it's not a simple transformation from a method to a
multimethod.)

> Why not call them "multifunctions"?

What about overloaded functions, which is the term used in C++ and
Java for a similar mechanism (that happens at compile-time -- but it's
standard Python practice to move things to run-time). We could then
also talk about overloaded methods when we're using the mechanism
inside a class.

Phillip Eby proposes "extensible"; but that's almost as meaningless as
"generic"; it has so many meanings already. "Function overloading" is
a pretty well-defined technical term with a narrow meaning that
applies well to this concept.

We already use the term overloading for operator overloading; I don't
think it's going to cause confusion though; C++ has the same double
use of the terminology. (As does Java, in the sense that it's commonly
know that "Java does not have operator overloading." :-)

I'll try to go with this for a while and see how it feels.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)