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 _______________________________________________ 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
