MooseX::Role::Strict on the CPAN

Ovid on 2009-04-30T17:48:54

I've an alpha of

{
    package My::Role;
    use MooseX::Role::Strict;
    sub conflict {}
}
{
    package My::Class;
    use Moose;
    with 'My::Role';
    sub conflict {}
}
# error message:
# The class My::Class has implicitly overridden the method (conflict) from role My::Role ...

This doesn't meet the needs of those who merely want the interface from roles and not the implementation, though. Thus, I've forked Moose to provide 'includes':

package My::Class;
use Moose;
with 'Some::Role' => { includes => [qw/foo bar baz/] };

Any method not in the 'includes' list is excluded and added to 'requires' to ensure the proper behavior of an interface. There are, however, a number of unanswered questions with this approach and I've asked the Moose list about them. Not sure if or when this will be accepted.

As a side effect of the 'includes' work, here's how to turn an entire role into an interface:

package My::Class;
use Moose;
with 'Some::Role' => { includes => [] };

However, this will probably be an error in the future as there are concerns that having the absence of information being meaningful might be problematic. I haven't yet figured out a better syntax, though.

What. The. Fuck.

mst on 2009-04-30T18:34:35

This is ... already a solved problem. Sartak's plan outlined here allows you to basically lint the code to catch this sort of thing, without running into the huge problem you've just caused of LETTING A RANDOM ROLE SUDDENLY FUCK OVER YOUR CLASS.

I mean, a MetaRole type thing that made it an error on a class by class basis would be great. What you've just done is randomly added compile time errors at a distance, without warning. I can see this as being perhaps acceptable for internal codebases, but I'd strongly ask you to make it clear that this should not be used in roles that you intend to ship to CPAN since they enforce policy on the consumer - and unexpected exceptions just because a module's author disagrees with the module's user about semantics really just aren't in the spirit of perl.

Errors Where They Belong

chromatic on 2009-04-30T19:38:45

I mean, a MetaRole type thing that made it an error on a class by class basis would be great.

That seems like the best option. Only at the point of role composition does a maintainer know enough about the use of the role to understand what's appropriate and what's not.
... unexpected exceptions just because a module's author disagrees with the module's user about semantics really just aren't in the spirit of perl.

Or roles, which exist to decouple the declaration of semantics from the mechanisms of implementing those semantics.