On Fri, Oct 14, 2005 at 09:08:45AM -0400, Rob Kinyon wrote: : What this means is that classes and roles both quack, swim, and : lay eggs. They're both just ducks. Given that, there's no need for two : separate concepts in the implementation. It just makes for a more : complex implementation.
I don't think they'll end up the same, quite. : I need to stress that I'm not suggesting that the keyword "role" : be removed. It won't be the first time we have keywords that mean the : same thing, just with a little sugar added. It definitely improves : maintainability to have separate keywords for separate ideas, even if : they're implemented identically. Certainly a different keyword can be used to convey a different intent. And because there's a different intent, we can have different defaults for them, at minimum. But I think it goes a little deeper than that. Not to put too fine a point on it, classes want to be open, and roles want to be closed. Let's not forget that the main point of roles is to commit to units of behavior that can be composed into classes (and other roles) at compile time. It's your basic mutable/immutable distinction. The compiler can rely on immutable values not changing. Now, we've said you can use a role as if it were a class, but you do it by generating an anonymous class of the same name. Er...yeah...something like that... Going the other direction, you could also use a class as if it were a role, but only by taking a snapshot of its current value. If you're planning to modify your base class after that, you'd better be using inheritance rather than composition, or the derived class won't see the change to the base class, and that would be unfortunate. It's bad enough that you might have to notify all the existing objects that one of its base classes has been modified. Doing that notification to objects of classes that have composed roles with compile-time assumptions would be a nightmare of pessimization. The first implementation of Perl 6 might not make use of optimizations based on compile-time composition, but we need to leave that door open. Generics are somewhat orthogonal to the mutable/immutable distinction, except that they're a better fit for roles because someone has to choose when to instantiate them, and they're easier to understand with early binding rather than late binding. So another way to view the role/class distinction is that roles have eager semantics while classes have lazy semantics. I expect it's possible to do lazy generics, but I would put it in the category of hard things that should be possible. Do I make myself perfectly muddy? :-) Larry
