Front page | perl.perl6.language |
Postings from December 2003
Re: Roles and Mix-ins?
From: Larry Wall
December 13, 2003 11:13
Re: Roles and Mix-ins?
Message ID: 20031213191230.GA18685@wall.org
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...