On Wed, 2005-05-18 at 10:51, Luke Palmer wrote:
> Except that mixins like this always treat things as "virtual".
> Whenever you mixin a role at runtime, Perl creates an empty, anonymous
> subclass of the current class and mixes the role in that class. Since
> roles beat superclasses, you'll always override your own methods.
Ok, good point (I've even pointed that out to others before, and I
missed it)...
I know that's the way it works, but now it's really bothering me.
There are many gotchas that fall out of that. For example, you might
have a special role that overrides .print to handle structured data, so
your code says:
my Foo $obj;
given $obj {
when StructuredPrintRole {
# Someone's already taken care of it, possibly
# adding a more specialized role, so leave it
# alone.
}
default {
# Add in a boring default handler
$obj does StructuredPrintRole
}
}
$obj.print($structured_data);
Woefully, you lose is Foo happens to be DECLARED with
StructuredPrintRole, and it overrode print. But, if it just inherited a
print(), then it works. In other words, this code will mysteriously fail
the second someone innocently adds a print method to Foo!
Action at a distance... my head hurts.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
