[Python-3000] Abilities / Interfaces

Jim Jewett jimjjewett at gmail.com
Sun Nov 26 03:56:06 CET 2006


On 11/22/06, Guido van Rossum <guido at python.org> wrote:
> On 11/22/06, Jonathan LaCour <jonathan-lists at cleverdevil.org> wrote:
> > Phillip J. Eby wrote:

> > > In essence, interfaces turn libraries into "frameworks", but generic
> > > functions turn frameworks into libraries.  I didn't really discover
> > > this until January of last year ...

> > This is easily the most important part of the conversation, IMO, and I
> > would hate for it to be missed. "Interfaces" in the Java universe are a
> > hard contract that everyone has to agree upon up-front, ... you end up
> > with is a world of many competing frameworks, none of which interoperate.

> > ... something that seems a tad magical at first
> > I have actually used generic functions (using RuleDispatch) in practice
> > and find them to not only be hugely powerful, but much more pragmatic.

> Sorry, but that was about as informative as a "+1" vote.

I found it a bit more specific on two points:

What I (mis?)read was:

(1)
PJE:  Interfaces rely on buyin; they end up accidentally creating
walled gardens.  Generic Functions make fewer demands, so they start
to work sooner, and integrate better.  [The down side is that finding
the relevant code -- or even being sure that it *is* is the relevant
code, and isn't overridden elsewhere -- gets more difficult. -jJ]

Jonathan:  Phillip has written a lot of long messages; this one point
is particularly important for the summary.  It captures a (the?) key
advantage of generic functions.

(2)
Generic Functions are harder to get your head around, but once you do,
they're worth it.  Phillip has been saying this already, but it
matters that someone else has gotten to the point where they are
useful and seem simple.

Personally, I stand by my assessment that they can make metaclasses
look straightforward -- but that is partly because metaclasses have
had their roughest edges worn off already.  (For example, they no
longer require compiling a C class so odd that the pattern gets named
after someone.)  If GF explanations start to come from several
different people, the same process should eventually simplify them.
If that happened quickly enough, it would change the tradeoffs.

-jJ


More information about the Python-3000 mailing list