Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Friday April 24, 2009
08:10 AM

Raising Moose In The BBC

[ #38863 ]

Seems the iBroadcast team in the BBC has now drunk the Moose Kool-Aid and they're happy with it. They're particularly happy with using roles instead of inheritance. They've found a bug with the excellent MooseX::Role::Parameterized and they'll be filing a report later. Basically, mixing normal and parameterized roles in a single 'with' statement caused the parameterized roles to be ignored (if I read the report correctly). This forces them to fall back to multiple 'with' statements until this is fixed.

That raises another issue. When you use multiple 'with' statements, you don't get the composition safety. What you do get is a predictable behavior, but one which is nonetheless surprising if you're thinking of roles as "mixins":

  package Role1;
  use Moose::Role;
  sub foo { __PACKAGE__ }

  package Role2;
  use Moose::Role;
  sub foo { __PACKAGE__ }

  package Foo;
  with 'Role1';
  with 'Role2';
  print Foo->foo;

If those roles were mixins, that would print 'Role2'. That actually prints 'Role1', not 'Role2'. This behavior is different from mixins which employ a "last wins" strategy. Since the first 'with' provides the 'foo' method, the second 'with' will see the method and silently fail to provide its own. The dev version of Moose (0.75_01) should warn if this happens.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • This "feature" is simply an artifact of how Moose must build classes (incrementally as each "keyword" is executed). There is also nothing (but common sense) to stop you from doing:

    package Foo;
    use Moose;
    extends 'Bar';
    extends 'Baz';

    Of course this behavior might be suprising to users who are used to having things pushed onto @ISA instead of @ISA being replaced.

    While I would not recommend multiple with statements in general, it is handy sometimes (as you pointed out in your post), so in the spirit

    • I also am not sure that I would advocate removing this feature. I've not found a use case for it, though, and there are huge potential downsides. That being said, I'm loathe to change the interface of working, widely used software, so I agree with your conservative approach :)