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 / [EMAIL PROTECTED] / http://blog.ianbicking.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
