in reply to Re: Moose role with requirement consuming another role
in thread Moose role with requirement consuming another role

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"

?



- Boldra
  • Comment on Re^2: Moose role with requirement consuming another role

Replies are listed 'Best First'.
Re^3: Moose role with requirement consuming another role
by Arunbear (Prior) on Jul 20, 2011 at 14:16 UTC
    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).
[reply]
      No, none of my roles are abstract base classes, they all provide additional functionality. Role::App reads the config file, creates objects based on its contents, and provides methods for fetching these objects.

      Anyway, I can't see how a class which inherits from another class (or a role) could be called an abstract base class - it's not at the base. But perhaps you are using a different definition.



      - Boldra
[reply]
        In a Java-like language, an abstract base class is often used to provide functionality (often mandated by some interface) to classes that inherit from it, but it cannot be used/instantiated on its own. "abstract" means that it can't be instantiated, it doesn't mean that it provides no functionality.

        This is how you are using Role::App. It is like an an abstract base class in the sense that it can't be instantiated and it provides functionality to App::FixIt. Some of that functionality is mandated by Role::Logger. What the docs are saying is that mandated methods have to be supplied in classes not in roles.

[reply]
[reply]

In Section Seekers of Perl Wisdom