[Python-3000] Abilities / Interfaces
Phillip J. Eby
pje at telecommunity.com
Wed Nov 22 21:54:20 CET 2006
At 12:28 PM 11/22/2006 -0800, Guido van Rossum wrote:
>So maybe there are even less differences between the different POVs.
Yep.
>I'm not arguing that generics aren't strictly more powerful than
>interfaces -- I just think that interfaces don't necessarily deserve
>the bad rep you're creating for them, and I'd like to have interfaces
>prominently in Py3k's toolbox (as well as generics) rather than having
>to hide them in the closet.
My point is that I'm not trying to create a "bad rep", I'm just emphasizing
that it's easier/more useful to define interfaces as collections of generic
operations, because it makes the simple cases simple and powerful, and the
complex ones possible. Doing it the other way around makes all of the
cases more complex, and loses other capabilities.
My use of the word "unnecessary" isn't a moral judgment of interfaces, it's
an argument about how best to layer the various concepts we want to
have. Interfaces aren't necessary for simple things, and it's better (IMO)
if we define them *in terms of* simpler things, because then people don't
have to learn about them unless they need something more complex.
And if they need something more complex, it is also more likely (I believe)
that they will have more specialized needs. So, I intended to suggest that
if we just do the basics (operations) and allow others to define interface
frameworks atop that, then we can avoid overgeneralizing from insufficient
experience. However, in the expanded discussion it seems to me that you
have goals for additional abilities you'd like to see sooner rather than later.
What worries me about Java-style interfaces is that you can't split and
recombine them in arbitrary ways, without effectively decomposing them into
single-operation interfaces using multiple inheritance. At which point,
you just might as well have treated them as operations to start
with! Thus, taking an operation-based approach means there need not be a
concept of the "one true sequence interface", just the *default* sequence
interface. If my needs are more or less expansive than the default
"sequence" interface, I should be able to do something like (sequence.len,
sequence.iter) and recombine a new interface.
This would also make the interface committee's job at least somewhat
easier. :)
More information about the Python-3000
mailing list