[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.

[Phillip J. Eby]

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 
anybody else.
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.