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.
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 base.pm 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 of TIMTOWTDI it will almost certainly stay as a "feature" even after we fix the incremental-class-building "issue".
- Stevan
Re:Feature or Bug, hard to say
Ovid on 2009-04-24T19:30:45
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
:)