[Python-3000] Traits/roles instead of ABCs
rasky at develer.com
Mon Apr 30 14:43:26 CEST 2007
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
> 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.
More information about the Python-3000