[Python-3000] Abilities / Interfaces

[Phillip J. Eby]

At 11:16 AM 11/22/2006 -0800, Robert Brewer wrote:
>Phillip J. Eby wrote:
> > The real problem here is that type inspection violates
> > encapsulation and the whole point of being "object-oriented"
> > in the first place.  The point of OO is that it lets you
> > *hide* the implementation.  If you put the implementation
> > in an if-then branch, you've just lost your OO-ness.
> >
> > The reason it's *tempting* to do this in Python, is because
> > we have so many convenient built-in data types that don't
> > have application-specific methods.
>
>Grrmbl. It's such a strong temptation, I'm not sure it's worth fighting
>in the interests of OO purity. I find myself constantly pushing
>teammates to favor builtins over custom types for exactly this reason;

I wasn't saying that doing it was a *bad* thing, I suggested we need things 
to help us do it *better* as a matter of course.  For me, if I'm not 
writing "throwaway" code, I pull type-testing operations out into separate 
functions, because more often than not, the *same* type testing operation 
will be used many times in the overall body of code.  This is just ordinary 
DRY to me, not any special "OO purity".

To be clear: OO purity isn't my goal.  Maintainability, reusability, and 
incremental implementation are the point.

Generic operations win out over interfaces as a fundamental concept because 
if you need the interface you can always make one *from* a set of 
operations.  And a lot of times, you only care about the one operation anyway.

Anyway, I'm beginning to see that the real problem in this discussion is 
that I tend to phrase "analog" ideas in a way that make other people think 
they're "digital" rules.  I've been mostly trying to say that the path of 
implementation (and perhaps teaching) should be:

     generics -> interfaces/typeclasses -> inspection ability

In other words, my references to "necessary" and "unnecessary" are not 
categorical declarations about the nature of programming, but rather are 
references to how "fundamental" or "incremental" the concept is in a 
constructive sense.  You can achieve all the use cases people have 
presented using generics only, without any formal notion of interfaces or 
the ability to do inspection.  (As Guido points out, this may not always be 
*convenient*, but it can be done.)

But the reverse isn't true: you can't really do what generics do, using 
only interfaces.  The generics are a more general solution, with interfaces 
and inspection being merely *convenience* features layered atop the more 
fundamental base.  And since generics are useful to have in their own 
right, it makes more sense (I argue) to start there.

In other words, this isn't some sort of moral judgment regarding the 
"purity" of interfaces or inspection, it's merely a comment about how best 
to *construct* them.  Building interfaces in the Java/Zope style (as mere 
collections of method names) loses you things that you can't just put back 
in later.