[Python-3000] Abilities / Interfaces

[Guido van Rossum]

On 11/22/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 09:24 AM 11/22/2006 -0800, Bill Janssen wrote:
> >I seem to spend a lot of time inside functions looking over values and
> >figuring out what to do do with them, actions which don't involve
> >invoking further functions, but rather operating directly on those
> >values in different ways.
>
> Whereas to me, that's an antipattern because that makes your code closed to
> extension.    What if somebody has a new kind of object that you didn't
> anticipate?

I'm sorry Phillip, but not all code needs to be open to extension.
There's an awful lot of bread-and-butter coding (including some of my
own :-) that really doesn't benefit from being open to extension.

> Interfaces don't solve the problem, they just kick it up to
> another level of abstraction, like hiding the dirty laundry under the rug.

There is a dangerous amount of content-free rhetoric in this thread.
(And I apogize from my own contributions.)

> 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.

OO is not religion, it's a tool, and it is not the only hammer we
have. As I've tried to mention through examples, there are plenty of
situations where a carefully placed if-then is a lot more practical
than adding a new method to some remote class (or several).

> 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.  In Java, where you have to create new types every time you turn
> around, and have method overloading anyway, you don't *do* this kind of
> type inspection.  It gets handled by type dispatching -- a primitive sort
> of compile-time only generic function!  It's considered bad style to write
> a huge block of 'ob instanceof IFoo' tests in Java, when you can just write
> overloaded methods.

True, some type testing code in Python would be done using overloading
in Java. But it doesn't always apply, for example when you're
examining objects that weren't passed as arguments but were maybe
gotten by accessing an argument's attribute, or pulled out of a
container, or perhaps produced by some factory function.

> In Java, SMTP.sendmail would be something like this (using Python-like
> syntax 'cause my Java is rusty):
>
>      def sendmail(self, from, to_addrs:str, msg, ...):
>          return self.sendmail(from_addr, [to_addrs], msg, ...)
>
>      def sendmail(self, from, to_addrs:list[str], msg, ...):
>          # main implementation

Right. If this syntax was possible in Python lots of people would be
very happy. But even the best generic function API I've seen is a lot
more verbose than this -- there seems to be a separate set-up
involved. A single if-then test does the same job with less fuss, and
when you need to support more types, it's easy to refactor to use the
GF approach.

> So, what I've been trying to say is that I don't think it's a good idea to
> copy Java interfaces without also copying the machinery that allows you to
> avoid 'instanceof' spaghetti.

It's not always automatically spaghetti. Often a single carefully
placed test is all you need. sendmail() grew that test long ago when
it was noticed that passing a string instead of a list was a common
mistake (a certain Googler with a single-letter username gets a lot of
junk mail occasionally :-). Nobody has felt the need to add more
branches to it in many years.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)