[Python-3000] Traits/roles instead of ABCs (original) (raw)

Collin Winter collinw at gmail.com
Mon Apr 30 19:14:34 CEST 2007

On 4/30/07, Talin <talin at acm.org> wrote:

Collin Winter wrote: > The key part of traits/roles is that, because the system is separate > from classes, you can do runtime role composition without a) mucking > with bases, or b) making isinstance() and issubclass() squishy and > ill-defined. By "runtime role composition", I mean it would be > possible to do something like this at runtime: > > py> int.implements(Ring) > > or (depending on your spelling preferences) > > py> Ring.implementedby(int) > > That is, it would be possible to distribute Jeffery's numeric kinds as > a third-party library and still have them affect the built-in numeric > types.

The question I have about all this runtime composition stuff is, what happens if different modules have different ideas about how things should be composed? How are conflicts resolved? With ABCs, we have a limitation that is also a strength: The mapping between ABC and its bases is either built-in to the ABC or built-in to the class, meaning that these decisions have to all be made up front - which forces the ABC implementer to pre-decide the outcome of all such conflicts before they happen.

What do you mean by "different ideas about how things should be composed"? Do you mean the case where two modules say the same class should do different roles? Roles are purely additive, so if module X says that class Z does one role, and module Y says class Z does another role, there's no conflict: the class does both roles simultaneously.

Things get interesting when you try to compose roles that both offer default implementations of the same method. The standard response (and the one chosen by Perl 6) is to just throw up your hands and shriek wildly and let the programmer sort it out. http://www.perlmonks.org/?node_id=384909 has a good example that addresses this exact question.

Collin Winter

More information about the Python-3000 mailing list