[Python-3000] pep 3124 plans

[Phillip J. Eby]

At 11:47 AM 7/23/2007 +1200, Greg Ewing wrote:
>With a normal method call, you can take an assumed
>run-time type, start at one end and follow things
>through step by step. That's not so easy with
>generic functions, for two reasons: (1) all of the
>arguments can potentially influence where the
>control flow goes, and (2) the overloading code
>can be anywhere in the program, not confined to
>the classes involved.

In order to follow things through with normal method calls, you have 
to know where a class is in the program, implying that you either 
search for it, or have read enough of the program to figure it out.

Which of these two things is different with generic functions?

(Meanwhile, if you are "starting at one end" and "follow things 
through step-by-step", then you are going to step right through all 
the method definitions, regardless of whether they're standard 
methods or GF methods.)


>I'm not saying this makes GFs impossible to use,
>but they do make the programmer's world considerably
>more complicated.

Since they make my world simpler, I'd have to disagree with such a 
blanket statement.  (I imagine the other developers who are using 
them would similarly disagree.)

If your argument is that it might make it more difficult for you to 
know what's going on in a poorly-organized program, or make it easier 
to write a poorly-organized program, I might agree with you.

But I disagree in the general case, because if you're going to be 
grepping for 'foo', it doesn't matter whether it's a method name or a 
generic function name -- you're still going to find all the definitions.


>You can't just brush these concerns
>off as being no worse than what OO already provides.

Actually I can, and just did.  Grep (or whatever global search tool 
your editor provides) is your friend.  It ain't perfect, but it's 
just as much required (and equally imperfect) for global analysis of 
a traditionally-OO program.