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