On Sat, Dec 13, 2003 at 04:57:17AM -0700, Luke Palmer wrote: : Chris Shawmail (E-mail) writes: : > I'm still digesting the vocabulary thread, but while I do, let me ask a : > question that's probably crystal clear to everyone else. : > : > Do roles act as a form of mix-in, as Ruby modules may, and Objective-C : > protocols do? : > : > Would the following two snippets be at all equivalent? : : Probably, depending on what's in the eventual definition of Foo. : : Roles are quite similar to mixins (as the Traits paper said that they : were inspired by mixins), but they're distinctly not the same. : : For one, one role's methods don't silently override another's. Instead, : you get, er, role conflict and you have to disambiguate yourself. For : two, you can attach new roles to an object at runtime (I don't know if : you can do this with mixins, actually).
Yes, you can. The mixin creates a new singleton class every time you do it, derived from the previous class. My current thinking is that run-time roles work a little differently. You get a singleton class for the object the first time you apply a property, so that each object's properties remain distinct. However, subsequent properties re-use the existing singleton class, and do the same role-conflict checks at run time that "does" would do in the class definition at compile time. Furthermore, the singleton class is not really derived from the original class, but just presents a different view of the same class, so that, from the viewpoint of the object, every role has the same standing, and run-time roles aren't privileged above compile-time roles, as they would be if the singleton class were really derived from the original class. In a sense, the object thinks it's recomposing the original class, but it's slightly wrong. If you really want new roles to override old roles, it's easy enough to throw a real derivation in there. But the Traits paper argues, and I'm inclined to agree with them, that this not what you want for the default behavior. Now the Traits paper was really only worrying about composing classes at compile time, and we're extending it to run-time. That means you can get name collisions at run time when you add a role. I still think it's better to catch that sort of goof earlier than later. That means the syntax for C<but> may evolve to look more like the syntax for C<does>. Whatever that looks like... Larry
