Guido van Rossum wrote:
> On 4/6/06, Phillip J. Eby <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
