[Python-3000] Abilities / Interfaces

[Gustavo Niemeyer]

> What does it add to have to declare a class as being "Iterable", if it
> already implements __iter__?  What does the notion of "Iterable" add
> to the execution *or* understanding of the code?

If you take a standard method which has a well documented meaning,
it's of course non-useful.

Now, let's say that you create a library named libfruit, and that
it implements a very nice IFruit interface.  This library is so nice
and shiny that it becomes widely used, and thus many ways to handle
a fruit are developed by third parties.  Now, someone else has a
libapple library, which unfortunately is a bit outdated, and wasn't
designed to work with the shiny libfruit library.

With interfaces, all you need to do is define an adapter from Apple
to IFruit, and instantly all the widely available frameworks will
be handling apples just fine.

Even though silly, this example describes some of the issues that
are common when handling libraries from several vendors.  Can you
describe how that'd work under your ideas?


> If you say that it is because having "Iterable" is needed to
> distinguish different possible interpretations of the same method
> name(s), then why not just have method namespaces to begin with?
> 
> "defop" is one way to do that, of course, but there could easily be
> others, like a "namespace" statement inside of classes that would
> contain the method definitions.
(...)

I'm sure there are many ways to get similar semantics to that offered
by interfaces. I can argue that a namespace like this would just take
ambiguity to a different level since it needs a name, or that it'd be
worse in terms of validation, or even that it'd take away some of the
benefits of introspection, and so on. But I don't see value in moving
on that kind of discussion here comparing a well established practice
and implementation with an idea which isn't clearly defined.


> 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, though, when I did some experiments in 
> replacing various PEAK interfaces with generic functions:

I'm sure these sentences have a well defined meaning in your mind,
but they seem extremmely vague from my perspective.


> The experience of refactoring was what made me realize that generic
> functions weren't just for obscure fancy use cases like security rules
> and binary math operators.  They *gutted* my interface-based code down
> to nothing -- hence my description of them as being "like acid for
> frameworks".

You seem to compare interfaces to generic functions.  As you
must be aware of, they're really orthogonal concepts.  You can
do adaptation and generic function-based code with or without
interfaces.

-- 
Gustavo Niemeyer
http://niemeyer.net