Aaron Sherman <[EMAIL PROTECTED]> writes:
> 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, you do realise that that's quite obscene code don't you? I mean, you're
doing a case statement based on the type of its topic, and to compound the
evils, you're changing how your topic's print method works *everywhere* simply
to get your 'special' print behaviour. If you must do something like this (and
call it print), then write it as a multimethod or something.
