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

[Phillip J. Eby]

At 08:29 AM 5/14/2007 -0700, Guido van Rossum wrote:
>On 5/14/07, Paul Moore <p.f.moore at gmail.com> wrote:
> > However, it looks like
> > there's a general feeling emerging that snipping certain sections
> > would be enough. I'd agree with that - my personal feeling is that
> > it'd be OK to remove all of the following sections:
> >
> > * "Before" and "After" Methods (as per Steven Bethard's suggestion)
> > * "Around" Methods (as per Steven Bethard's suggestion)
> > * Custom Combinations (as per Steven Bethard's suggestion)
> > * Interfaces and Adaptation (doesn't feel like a core aspect of 
> the proposal)
> > * Aspects (as per Steven Bethard's suggestion)
> > * Extension API (currently empty, and that hasn't hampered the 
> discussions!!)
> >
> > I'd be OK with them going into an additional PEP, but to be honest, it
> > wouldn't bother me to see them left out of the PEP process
> > altogether[1]. (I don't feel that I have enough experience with
> > *using* GFs to comment meaningfully, so I'd be willing to defer to
> > Phillip's judgement here).
>
>That would suit me fine, since my inclination is to approve some form
>of the basics of the PEP (with reservations I will explain in another
>message) but to reject the second PEP.

FYI, wrt to Paul's list, my own list for the 2nd PEP doesn't include 
interfaces and adaptation; they'd be squarely in the first PEP.


> > [1] But I'd like to see them documented in the final implementation -
> > I'm not suggesting they be undocumented features.
>
>I'm suggesting they aren't features at all, except for the extension
>API. All the other stuff should be addable in a separate module using
>the extension API.

I don't see what the benefit is of making people implement their own 
versions of @before, @after, and @around, which then won't 
interoperate properly with others' versions of the same thing.  Even 
if we leave in place the MethodList base class (which Before and 
After are subclasses of), one of its limitations is that it can only 
combine methods of the same type.  There's no way for two different 
user-implemented "befores" to merge at the same precedence level, 
without some fairly fancy footwork on the implementer's part, or some 
kind of convention being established as to how to tell whether a 
method intends to be a before or after or whatever.  (And this 
same-precedence merging is critical feature of @before/@after, as 
they are used mainly for "observer"-like hooks, where multiple 
libraries may be observing the same thing.)

So, one of the reasons for including those features (along with 
Aspect) in the stdlib is the standardization part.  Really, 
standardization of a lot of this stuff is the main point to having a 
PEP at all.

By the way, I'm not sure if I mentioned this before, but Ruby 2.0 is 
supposed to include before/after/around qualifiers, except they're 
called pre/post/wrap, and I'm not sure if the combination rules are 
100% the same as my before/after/around.  And they're using Ruby's 
open classes rather than standalone generic functions.  But it's 
another data point.

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.