[Python-3000] Kill "generic functions"!

[Guido van Rossum]

On 4/6/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> I have two problems with "overload":
>
> 1) You have to already be a programmer to make any sense of the term...

You gotta be kidding. This wouldn't be true for other terms like class
or method? I really don't care about non-programmers "getting" this
the first time they hear about it; especially not such a relatively
advanced feature (I don't expect this to show up in the CS1 textbook
about programming by John Zelle, for example, until perhaps the last
chapter whose main purpose it is to whet your appetite for CS2...).

> 2) ...and in any place you've seen it before, the overloading is
> *static* and completely unlike this kind.

And as I said, Python moves stuff to run-time all the time.

If you don't have a better argument against "overloaded", then
"overloaded" it is.

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

Well, the same is true for concepts like "class", "import", and
"variable". Tese all have dynamic run-time meanings while they are
compile-time concepts in Java/C++.

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

I disagree on principle -- if you were to invent a mechanism to do
function overloading purely at run-time, then surely you would come up
with something akin to what we're planning to do here.

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

And I respectfully disagree. Python's predecessor, ABC, introduced a
boatload of new terms because they were afraid the traditional terms
would be misunderstood by newbies. I intentionally didn't borrow any
of those terms (except list, which I gave a totally different meaning
:-), going back to traditional terms. I don't want Python to add to
the language except for the word "Pythonic".

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