[Python-3000] Kill "generic functions"!

[Ian Bicking]

Phillip J. Eby wrote:
> As long as we're inventing our own terminology, I vote for 
> "extensible functions", as this emphasizes the benefit rather than 
> the technology.  Without extensibility, there's nothing really 
> special about them.  We wouldn't even be talking about them if you 
> had to define all of their "methods" in one place.

Extensible is kind of vague.  Dispatching functions?  The idea is that 
you have a kind of central function, but there are several actual 
implementations, one of which is used.

There's also the thing-that-gets-dispatched-to.  Calling these "methods" 
is probably a bad idea, because we already have dispatching methods in 
addition to dispatching functions.  Some ideas:

* Specific (specified?) functions
* Dispatching implementations
* Just "implementation"
* Concrete functions or concrete implementations

I think "extensible" or other extend-ish terms imply a purpose, not a 
mechanism.

"Multimethod" or "multifunction" refers to dispatching on multiple 
arguments based on type (where current class dispatch is done by 
dispatching only on the type of the first argument).  Generic functions 
can do more than type dispatching, and anyway few people think of 
methods as single-argument type dispatching, so the referring to 
multi-argument type dispatching as simply "multi" is pretty vague.

Guido suggests "overloaded functions", which also seems pretty 
reasonable to me.  "Overloaded" implies that there's more than one 
implementation for this thing -- in part it implies this because of the 
C++ terminology, but also creates images of a function as a container, 
which is a useful and accurate way of thinking of this.  What to call 
the implementations is still an open issue then.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org