Well, it depends. If you are using roles, there are a couple of ways of resolving conflicts, but basically it works out as:
class Elf is Character does Thief does Scout {
method hide { .Scout::hide(@_) }
...
}
However, if you prefer, you can have your cake and eat it too.
method hide ($self: $action) {
# $self is required here because the topicalizer assigns
# $action to $_
given $action {
when Skulking { $self.Thief::hide($action) }
when Stalking { $self.Scount::hide($action) }
}
}
And that's nice because theoretically, if your elf knows various professions, she should know how the activities with those professions vary, just as one person might know how to drive a race car but wouldn't think of doing that with a dump truck, even though both activies are driving.
Unfortunately, when it comes to your specific example with mixins, I'm a little less clear about disambiguation. When you use a role at runtime on an instance, you get new anonymous classes that are related to the instance via inheritance. Thus, the following has the inheritance ordering problem again:
$elf does Thief does Sentry;
In that example, $elf.hide calls Sentry.hide as Thief.hide is further up the inheritance tree. This seems to limit the utility of mixins, but I can't be sure. Further clarification would be nice.
|