At 10:31 AM 11/22/2006 -0800, Guido van Rossum wrote: >In *my* notion of abilities, this part being inspired by Zope >interfaces, you can state after the fact that a particular class >(which you didn't write) provides a given ability (which you didn't >write either). I think it would also be great if we had "ability >algebra" whereby you could state that a given ability A is composed of >existing abilities A1 and A2, and every object or class that already >has A1 and A2 will automatically be considered to have A. > >However, I do *not* want to go the way of duck typing here -- if an >ability A claims that it is implemented by method foo(), and an object >x has a foo() method but doesn't explicitly claim to have ability A >(and neither does its class), then testing x for A should return >false. I think this deviates from Haskell, which seems to be big on >structural type equivalence (?). > >So I think Python needs to do its own thing here, to some extent.
Actually, you just described Haskell typeclasses. :) That is, they are: 1. Able to be specified after the fact 2. Are algebraically defined as sets of operations 3. Strongly typed based on functions With respect to #3, I think you are confusing Haskell function names with Python method names. Typeclasses also have one more ability that you didn't include above: 4. Able to provide implementations after the fact, not merely declarations This is basically the same concept as adaptation and generic functions, so that you can not only *declare* that a type meets an interface, but also provide a way to make it work. So, we are in agreement on some basics, I think. I am mainly concerned that we do not treat interfaces as collections of method names, rather than collections of operations. (Attributes can be considered operations to read, write, or delete them, and in many cases you will want to specify those operations individually in an interface/typeclass). In Haskell, however, it is not that common for ordinary code to define or use typeclasses, since direct use of the operations (e.g. len()/iter() equivalents) normally suffices to imply the typeclass(es) involved. Also, like Java, Haskell selects overloaded implementations based on their argument type, so you don't write "if isinstance" tests either. Generics reduce the need for type testing and explicit interfaces, since you can just use an operation rather than needing a method (as in Haskell) or you can define overloads to select an implementation (as in Java). In Python, however, interface libraries have historically treated their operations as simply a bag of method names and call signatures, which doesn't allow algebraic operations and introduces the need for explicit adapter types. In contrast, an operation-based approach (where interfaces are collections of first-class "operations" of some kind, that can be recombined to create new interfaces) allows both interface algebra and *automatic* adapter generation (as described in my "monkey typing" proposal early last year). _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
