[Python-3000] Kill "generic functions"!

[Phillip J. Eby]

At 10:07 AM 4/6/2006, Ian Bicking wrote:
>I think "extensible" or other extend-ish terms imply a purpose, not 
>a mechanism.

Which is why it's a good thing, IMO.

>"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).

Actually, IIRC, "multi function" is actually a distributed 
programming term and means something else entirely.  Also, it's a 
really lousy word for Googling.  :)


>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.

I have two problems with "overload":

1) You have to already be a programmer to make any sense of the term...
2) ...and in any place you've seen it before, the overloading is 
*static* and completely unlike this kind.

In Java and C++, any overloading that takes place has to be known 
statically to the compiler.  Not only does it have to know all the 
*definitions* involved in the overloading, it also statically 
determines what will be called at the *call sites*.  That is, for an 
overloaded function F, the Java or C++ compiler knows for every call 
of F(), what overloaded version of F will be invoked.  Runtime types 
have *zero* to do with it.

So overloading and extensible functions are different in two ways:

1. New overloads are added at runtime
2. Implementation selection occurs at runtime

It's possible I'm overreacting here, of course.  Maybe a typical Java 
or C++ programmer, upon being exposed to this kind of overloading, 
will shout "hurrah! That's what I really wanted anyway".  In fact, 
I'm rather sure they will.  What I'm really more concerned about is 
that they won't *know* that it does that because of "verbal 
overshadowing" - the term being so strongly associated in their minds 
with another concept that it will be hard to get them to 
notice.  From an educational POV, it seems to me better to use a term 
that is either completely new (which you can then say is a kind of 
"dynamic overloading"), or else borrow a term from a language that 
actually has the same thing.

For example, many functional languages have "pattern matching", which 
is similar to this in that implementation selection occurs at 
runtime.  The part that's different is that pattern-matching 
languages generally require you to define all the patterns in one 
place, with no extensibility.  And so "extensible pattern matching" 
could work, except it's too bloody long, especially as an adjective 
for "function"!

So, when it comes right down to it, the only existing terminology 
used in other languages that precisely matches this thing is "generic 
function".  And in languages where they're called generic functions, 
the things in them are called methods.

I think that Python has a reasonable chance to invent a new term for 
these things and make it stick, but I don't think that overloading 
"overloading" with even more meanings than it already has is a good idea.  :)