[Python-3000] Traits/roles instead of ABCs

[Collin Winter]

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.implemented_by(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