[Python-3000] Traits/roles instead of ABCs

[Giovanni Bajo]

On 30/04/2007 3.40, Collin Winter wrote:

> The mechanism I'm most familiar with for solving this problem (which,
> unless I've missed something, is, "how do I make sure this object does
> what I expect?") is Perl 6's roles system; if you know about Squeak
> Smalltalk's "traits" system, you're on the same page.

+1. I like those, *specifically* the fact that they can be dynamic (you can 
"add" a role to a class or an instance of a class and "remove" it later). This 
is basically mixins they way they should be done.

> The idea is that we leave the traditional class system to manage an
> object's implementation and use a more-or-less orthogonal system to
> manage that same object's behavior.

Yes. In other words, traditional inheritance is very good for *reusing* an 
implementation, but it's not very flexible for defining behaviour. It works 
for basic cases of course, but gets limited fast when your object network gets 
more complex.

> 2. I gave a strawman syntax proposal for runtime role composition
> above (modulo the method name): "Ring.done_by(int)" or
> "int.does(Ring)". (Perl 6 speaks in terms of "an object/class *does* a
> role".) Perl 6 also allows individual instances to do different roles
> than their class does, but I'm not sure we want to go that far.

Well, I do! I know there have been times I have needed it badly, and when 
you're there there's little you can do. If you want to champion a "role" 
proposal for Python, please don't forget about this.
-- 
Giovanni Bajo