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.)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
