[Python-3000] Kill "generic functions"!

[Nick Coghlan]

Guido van Rossum wrote:
> On 4/6/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>> So, when I say that "overload" has the wrong connotations, I'm not
>> talking about some abstract understanding of what it is or does, I'm
>> talking about the wrong connotations for their practical intuition of
>> how the thing should be *used*.  The use cases for overloading in the
>> languages that have it are way different, and if you move those
>> concepts over to generic functions without a critical
>> reinterpretation of the concept, you will write atrocious Python that
>> will be hard to read and perform badly.
> 
> I think that the solution to this would be a book or course "Python
> for Java programmers". Not using the most natural name for a feature
> because Java programmers might misunderstand it sound like the wrong
> motivation.

The problems I have with "overload" are that the adjective form is lousy, the 
noun forms are identical to some of the verb forms, and the *English* 
connotations are bad. My own suggestion of "specialize" (mentioned somewhere 
in the generic functions thread) is just too damn long. "extend" doesn't have 
any of these problems.

=== Noun and Verb forms ===

A quick side-by-side word form comparison:

Verb forms:
   extend       overload
   extending    overloading
   extended     overloaded
   extends      overloads
Adjective forms:
   extensible   overloadable
Noun forms:
   extension    overload
   extensions   overloads

And some comparative sentences using those terms:

   Py3k functions will be extensible
   Py3k functions will be overloadable

   Function extensions are used to extend extensible functions
   Function overloads are used to overload overloadable functions

   An extended function may delegate a call to one of its extensions
   An overloaded function may delegate a call to one of its overloads

Here's an example of registering a function extension:

      @extend(str).for_signature(SomeClass)
      def stringify(obj):
           return obj.stringify()

No problem here - this function extends the "str" function when that function 
is called with an object of type "SomeClass".

Now here's the exact same example as a function overload:

      @overload(str).for_signature(SomeClass)
      def stringify(obj):
           return obj.stringify()

Uh-oh - now the verb/noun duality of the word "overload" comes back to bite 
us. Are we registering that "str" is a known overload of *this* function? Or 
that this function overloads "str"? The latter is definitely the more likely 
interpretation, but there's still room for a bit of doubt.

=== English connotations ===

On the topic of "overload" as an English word, I've always suspected whoever 
chose it for the concept of signature-based function dispatch was deliberately 
trying to discourage people from using overloaded functions. Overloading 
something or someone is normally considered a very *bad* thing, as it means 
asking that thing or person to do more than it or they can handle. When a word 
is described as being "overloaded with meanings" it generally means that the 
word has *so many* meanings that it can no longer be used safely if you desire 
clear communications.

So I consider "overload" to be far from a natural term for a mechanism that's 
perfectly safe, and believe there are some very sound reasons to prefer the 
name "extensible functions".

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org