[Python-3000] Traits/roles instead of ABCs
Talin
talin at acm.org
Mon Apr 30 18:27:29 CEST 2007
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.
-- Talin
More information about the Python-3000
mailing list