[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
Phillip J. Eby
pje at telecommunity.com
Mon May 14 21:40:39 CEST 2007
At 09:41 AM 5/14/2007 -0700, Guido van Rossum wrote:
> > Note that in current Ruby, you can simulate generic functions
> > (single-dispatch only) via open classes as long as you use
> > sufficiently-unique method names. The fact that Matz wants to add
> > these qualifiers seems to suggest that simple next-method chaining
> > (i.e. super) isn't as expressive as they'd like. Unfortunately, I
> > haven't been able to find an RCR for this feature, only references to
> > RubyConf slide presentations, so I don't know what their specific
> rationale is.
>So if Matz jumped off a cliff, would you recommend I jump too?
If we're using cliff-diving as a metaphor for generic functions, I'd
say that method combination is more comparable to saying that if Matz
decided he'd like to have a swimsuit next time he went cliff-diving,
then I would recommend that you consider whether you might like to
take a swimsuit as well, were you planning your first such dive. :)
In practice, however, I wasn't recommending blindly following Matz or
I simply said the plan for Ruby was suggestive that method
combination is worth looking into further, because in the case of
Ruby, they already had single-dispatch generic functions, so the
addition suggests combination is no longer considered a YAGNI there.
As I said, however, I unfortunately haven't been able to find any
documented rationale for the proposal -- implying that I have no idea
whether Matz' decision is more comparable to jumping off a cliff or
packing a swimsuit, and thus cannot give any actual recommendation
with respect to such. :)
I simply mentioned the subject in case anybody else knew more about
the rationale or where to look for the RCR (if one exists). That is,
I think it would be useful to know why there was interest in adding
such a feature there.
Anyway, that's hardly the same as recommending you jump off a
cliff. Indeed, it wasn't a recommendation of any sort at all, just a
comment on my investigation into useful references for the PEP --
i.e., something that you asked for more of.
As for actual code, I'm looking now for examples from people's code
besides mine. The canonical use for me is separating business rules
like "@after sell(cust:GoldCustomer, prod:FooProduct):
email_regional_sales_mgr()" from reusable library code, so that
"enterprise" developers can add business rules to an upgradeable core
library maintained by a vendor or architect. Of course, I'll also
use them to do debug prints or drop into the debugger.
Meanwhile, I've been told repeatedly that TurboGears makes extensive
use of RuleDispatch, and my quick look today showed they actually use
a custom method combination, but I haven't yet tracked down where it
gets used, or what the rationale for it is.
It doesn't appear to be used in the core TurboGears package, so I
suppose it must be in the various add-ons, which I haven't had time
to go through yet. Their custom method combination does *support*
before/after/around methods, but their core tests only tested
"around" methods that I saw.
More information about the Python-3000