Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Re: Solving compositional problems with Perl 6 roles

by kappa (Chaplain)
on Aug 22, 2004 at 09:37 UTC ( #384909=note: print w/replies, xml ) Need Help??

in reply to Solving compositional problems with Perl 6 roles

Is there a method to resolve ambiguities when $elf does Thief does Scout and both Thief and Scout can hide, only differently?

Replies are listed 'Best First'.
Re^2: Solving compositional problems with Perl 6 roles
by Ovid (Cardinal) on Aug 22, 2004 at 14:41 UTC

    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.


    New address of my CGI Course.

      Ultimately, it appears that the crux of the matter is defining what is a behavior vs. what is a trait.

      A thief IS a Character who "implements/HAS" the behavior/interface of methods associated with "thieving". An Elf is a Character who IS a type of Character, who HAS certain additional traits.

      It's all going to come down to whether you think of the character as an "elf type-of thief," or a "thief type-of elf." This will determine which is the child class by inheritance, and which is the child by "mix-in".

      Just some thoughts,
      "Perl. There is no substitute."
        Would be nice to NOT know whether $stranger is an "elf type-of thief" or "thief type-of elf" and be able to do this:
        # ".?" means "call if the obj CAN the method" acc. to Apoc12 $stranger.?steal; $stranger.?shoot_arrows;
        and expect DWIMming (doing both things in both cases). That's the whole point of polymorphism, is it not? :)

        Update: upgrade perl5 syntax to perl6 (Apoc12).

      Your interesting node made me reread the Apocalypse. I stand admired (again) and await being able to call ALL the matching methods from all the roles of my little elf (via $elf.*hide) or even choose which ones I like to skip.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://384909]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (3)
As of 2021-07-30 12:00 GMT
Find Nodes?
    Voting Booth?

    No recent polls found