[Python-Dev] Single- vs. Multi-pass iterability

[Clark C . Evans]

On Mon, Jul 15, 2002 at 08:15:11AM +0200, Alex Martelli wrote:
| >
| >    Well, if it ain't a Thymagig, where is the
| >    wrapper so I can treat it like one?
| >
| 
| Right.  The concept of adaptation definitely comes from the Components
| world, where "is-A" is a dirty word.  High time the Objects world 
| listened:-).

*grins*

| Whether reifying the concept into a type or language-blessed
| category buys you more than it costs -- much depends on how it's
| done.  Personally, I'd rather have that superset of "interface" that
| is known in Haskell as a "typeclass" -- and I'd settle for that middle
| ground that is known in C++ or Java as an "abstract class".  If
| interfaces/typeclasses/&c came with Eiffelish 'contracts', so much
| the better.  But it's all in the narrow range between -0 and +0 for me.

I could see where something like Eiffel's "contracts" would be a
neat addition to Python, but I must confess I don't have any serious
experience with them. 

| I'm not sure what you mean by "interface inheritance".  The ability
| to define an interface by adding some stuff to another interface --
| that's the only sense in which one could possibly speak of such
| a thing in Java, say -- is extremely convenient but not a must-do...

My exposition was awful, sorry.   Perhaps a specific (albeit contrived)
example would better reflect the intent.   Suppose that I have a iterator
with one method, next().   Now suppose that I want a "mutable iterator",
one which adds the change() method.   This is well and good, but the
concept of something being mutable is quite othogonal to iteration and
perhaps should have its own interface rather than using inheritance.
So, what I'm asserting is that once the inheritance "feature" is 
there... people use it even though other approaches are available.

Once headed down this path, people start defining these massivly
ugly interfaces (see XML's DOM) where "lazy" implementations throw
a NotImplemented error if the object doesn't support particular
methods of the interface.   Yikes.  The other thing that interface
inheritance implies is substitutabilty; yet in practice this isn't
always practical (or even needed).   

But, alas we are digressing here.  The point of the PEP wasn't to
confront interfaces; as people who believe in them won't be swayed.
But frankly... I love python without interfaces.   

| The big question is rather: given that Isub inherits from Isuper,
| does any object implementing Isub also implicitly implement Isuper?
| 
| That's the object-philosophy, where inheritance is thought to reflect
| deep IS-A relations.  It's NOT the component-philosophy, where
| inheritance is an implementation-convenience detail.  I much prefer
| the component-approach, where my component has full control, if
| it wants to, on exactly what interfaces it exposes.  This lets you
| factor out any commonality between interfaces without giving any
| actual reality to the factored-out common subset -- it can even stay
| an "abstract interface" that no object actually supplies, if you want.

Yes, this is the bigger question.  And I'd rather see python swing
more towards the component/delegation model; it isn't really strictly
object oriented as it is, and I'd hate to see it become that way.

Best,

Clark
Yo! Check out YAML!  http://yaml.org
Serialization for the masses