[Python-Dev] PEP 246: lossless and stateless

[Phillip J. Eby]

At 10:02 AM 1/14/05 -0800, Michel Pelletier wrote:
>I get it!

Thanks for the positive feedback, I was getting worried that I had perhaps 
gone quite insane during the great debate.  :)


>   Your last description didn't quite sink in but this one does and
>I've been thinking about this quite a bit, and I like it.  I'm starting to
>see how it nicely sidesteps the problems discussed in the thread so far.

Good, I'll try to cherry-pick from that post when writing the PEP.


>Does anyone know of any
>other languages that take this "operational" aproach to solving the
>substitutability problem?

This can be viewed as a straightforward extension of the COM or Java type 
models in two specific ways:

1) You can implement an interface incompletely, but still receive a partial 
adapter
2) Third parties can supply implementations of individual operations

Everything else is pretty much like COM pointers to interfaces, or Java 
casting.

Of course, as a consequence of #1, you also have to declare conformance 
per-operation rather than per-interface, but some syntactic sugar for 
declaring a block of methods would be helpful.  But that's a detail; 
declaring support for an interface in COM or Java is just "like" 
automatically adding all the individual "like" declarations.

Alternatively, you can look at this as a dumbed-down version of protocols 
or typeclasses in functional languages that use generic or polymorphic 
operations as the basis of their type system.  E.g. in Haskell a 
"typeclass" categorizes types by common operations that are available to 
them.  For example the 'Ord' typeclass represents types that have ordering 
via operations like <, >, and so forth.  However, you don't go and declare 
that a type is in the 'Ord' typeclass, what you do is *implement* those 
operations (which may be by defining how to call some other operation the 
type has) and the type is automatically then considered to be in the typeclass.

(At least, that's my understanding as a non-Haskell developer who's skimmed 
exactly one tutorial on the language!  I could be totally misinterpreting 
what I read.)

Anyway, all of these systems were inspirations, if that's what you're asking.


>There seem to be some downsides vs. interfaces (I think) the lack of "it's
>documentation too" aspect, I find zope 3 interfaces.py modules the best way
>to learn about it, but again the upside is, no complex interface
>relationships just to define the subtle variations of "mapping" and users can
>always just say help(file.read).

It doesn't *stop* you from using interfaces of whatever stripe for 
documentation, though.  The target type can be abstract.  All that's 
required is that it *be* a type (and that restriction might be loosen-able 
via an adapter!) and that it have descriptors that will indicate the 
callable operations.  So Zope interfaces still work; there's no requirement 
that the descriptor something is "like" can't be an empty function with a 
docstring, like it is in a Zope or PyProtocols interface.


>Another thing I see used fairly commonly are marker interfaces.  While I'm 
>not
>sure of their overall usefullness I don't see how they can be done using your
>operational scheme.

Add an operation to them, or an attribute like 'isFoo'.  Then declare an 
implementation that returns true, if the appropriate object state 
matches.  (I presume you're talking about Zope's per-instance marker 
interfaces that come and go based on object state.)


>   Maybe that means they were a bad idea in the first
>place.

Probably so! But they can still be done, if you really need one.  You just 
have to recast it in terms of some kind of operation or attribute.


>I also think this is easier for beginners to understand, instead of "you have
>to implement this interface, look at it over here, that's the "file"
>interface, now you implement that in your object and you better do it all
>right" you just tell them "call your method 'read' and say its 'like
>file.read' and your thing will work where any file can be read.

You don't even need to call it read; you could use the word "read" in the 
non-English language of your choice; any code that wants a "file" will 
still be able to invoke it using "read".  (And English speakers will at 
least know they're looking at code that's "like" file.read.)