Moose role with requirement consuming another role

[Boldra]

I want a role to consume another role, and provide an attribute that the consumed role requires, but Moose won't see the attribute provided by the first role.

An example:

package Role::Logger;
use Moose::Role;
requires qw<smeg>;

package Role::App;
use Moose::Role;
has smeg => ( is => 'rw' );
with 'Role::Logger';

package App::FixIt;
use Moose;
with "Role::App";
sub run {
   print "smeg=" . shift->smeg;
}
package main;
use Moose;
App::FixIt->new( { smeg => 1 } )->run;

This code returns the error 'Role::App' requires the method 'smeg' to be implemented by 'App::FixIt'. But Role::App doesn't have any requirements, it's Role::Logger which requires smeg, and smeg is provided by Role::App.

The Moose documentation to required attributes warns that a requirement met by an attribute in a consuming class must be met before the role is consumed, so:

package Role::App;
use Moose::Role;
requires 'gazpacho';

package App::FixIt;
use Moose;
with Role::App;
has gazpacho => ( is => 'rw' );

breaks because the requirement is met after the role is consumed. Here, swapping the order of with and has solves the problem. OTOH, requirement met by a subroutine would also be ok, because the subroutine is defined before with imposes the required constraints at runtime.

In summary: If a role requires a method and the requirement is met by:

a sub in a consuming class	No problem
a sub in a consuming role	No problem
an attribute in a consuming class	be careful of the has/with order
an attribute in a consuming role	can't be done?

Thanks for your thoughts!

[moritz]

I don't quite understand your approach. If role Role::App requires the attribute gazpacho that role App::FixIt provides, why not not simply compose App::FixIt into Role::App?

[Boldra]

My second example (with gazpacho), was really just meant to show that I understand the importance of the with/has order when a class consumes a role. Perhaps I over-emphasized it.

The real problem is not with class<-role(requirement), but, similar to my first example, class<-role<-role<-role(requirements). Or to go into yet more detail, I have about 30 app classes which consume one of two specialized App roles, these both consume a generic App role, which consumes three further roles, MooseX::Getopt, MooseX::SimpleConfig plus our own app-logger role.

I can easily drop the requirement in the app-logger role and everything works fine. I'm just curious if there is a better solution.

[Arunbear]

Your Role::Logger role looks like an "interface role" in the sense described in Roles Versus Abstract Base Classes, and your Role::App is being used like an abstract base class.

But this type of usage doesn't seem to be (officially) supported

[Boldra]

I can see how my simplified example matches that description of an interface role, but in reality the Logger Role has six attributes and 200 lines of code, it's not just a list of 'requires'.

"this type of usage doesn't seem to be (officially) supported" == "I can't find it in the doc either"

?

[Arunbear]

Role::App being used like an abstract base class is what is at odds with the documentation (regardless of whether or not the Logger Role is an interface type role).

[nysus]

I'm almost 6 years late to this conversation but this worked for me:

{
  package MyOpenSSH 0.000001;
  use Moose::Role;
  has 'ssh' => (is => 'rw', isa => 'Str', required => 0, lazy => 0 );
}

{
  package Apache2Info 0.000001;
  use Moose::Role;
  requires 'ssh';
}

{
  package WebServerRemote 0.000001;
  with 'MyOpenSSH';
  with 'Apache2Info';
}

The trick seems to have been to put the with statements on two different lines and putting the role with the required attribute first in the list.

[preaction]

I just ran into this problem myself, and I fixed it by simply removing the requires. They're just guidelines, I guess.

If there's a way to get this working, I'd love to know.