At 08:51 AM 4/6/2006, Aahz <[EMAIL PROTECTED]> wrote:
>I cringe every time I see the phrase "generic function". It's way too
>generic -- it doesn't contain any hint of its meaning,
And worse - "generic" in US English often implies:
* commodity
* ordinary
* cheap knock-off
* low-quality
etc. Not the sort of ideas to associate with Python. :)
>and I find it
>confusing because Python already has what I think of as generic
>functions:
>
>def adder(a, b):
> return a+b
>
>That's a perfectly good generic function that depends on Python's
>duck-typing. "Multimethods" works, but Python is in many ways
>function-oriented rather than method-oriented. Why not call them
>"multifunctions"?
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.
We also need a term for their methods, as this gets confusing when
talking about a gener^H^H^H^H^Hextensible function that's being used
as an object method. I don't have as unequivocal a suggestion for
that, but lean towards "extensions". So, you would "extend" an
extensible function by adding an extension:
@extensible
def some_function(...):
"""blah"""
@some_function.extend(...)
def other_thing(...):
"""bah"""
Although, depending on how extensibility is implemented, I'd suggest
that in Py3K there should be no need for @extensible; functions could
simply be extensible by nature, in which case, this would be sufficient:
def some_function(...):
"""blah"""
@extends(some_function, ...)
def other_thing(...):
"""bah"""
Note that @extends() itself could be a function that is extensible,
which could open the door to alternative means of doing the
extending, so that people could have add-on libraries providing more
advanced forms of extension that what the language itself might
provide. (e.g. RuleDispatch's level of customizability)
I understand that Ruby 2 is probably going to add before/after/around
decorators that basically provide a form of @extends that allows you
to monkeypatch an existing method. If that's all that was built in
to Python 3000 (i.e., a way to monkeypatch a function without messing
with func_code), then all the more sophisticated forms of generic
functions could be implemented on top of that. And for really simple
situations, like where you want to just add *one* more extension to
an almost perfect function, that monkeypatching ability alone would
work great, especially if it could be done in such a way that
invoking the previous definition of the function didn't create
function call overhead. As soon as you add a few levels of function
call, RuleDispatch's dispatch tree starts looking speedy by comparison.
Anyway, syntactically, that would probably look like:
@extends(some_function)
def some_extension(...):
if some_condition:
...
else:
next_method(...)
And then other people could make fancier versions of @extends that
put the conditional information into the decorator arguments instead
of the function body.
_______________________________________________
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
