Ports Search

A logging role building a very lightweight wrapper to Log::Log4perl for use with your Moose classes.

MooseX::Meta::TypeConstraint::ForceCoercion allows to wrap any Moose::Meta::TypeConstraint in a way that will force coercion of the value when checking or validating a value against it.

MooseX::Method::Signatures provides a proper "method" keyword, like "sub" but specifically for making methods and validating their arguments against Moose type constraints.

This module is meant to be loaded as a role from Moose-based classes it will add five methods and four attributes to assist you with the loading and handling of plugins and extensions for plugins. I understand that this may pollute your namespace, however I took great care in using the least ambiguous names possible.

This module fills a gap in Moose by adding method parameter validation to Moose. This is just one of many developing options, it should not be considered the "official" one by any means though.

Extensive, yet simple, logging role using Log::Dispatchouli

MooseX::Role::Matcher - generic object matching based on attributes and methods

Roles are composable units of behavior. They are useful for factoring out functionality common to many classes from any part of your class hierarchy. See Moose::Cookbook::Roles::Recipe1 for an introduction to Moose::Role. While combining roles affords you a great deal of flexibility, individual roles have very little in the way of configurability. Core Moose provides alias for renaming methods and excludes for ignoring methods. These options are primarily (perhaps solely) for disambiguating role conflicts. See Moose::Cookbook::Roles::Recipe2 for more about alias and excludes. Because roles serve many different masters, they usually provide only the least common denominator of functionality. To empower roles further, more configurability than alias and excludes is required. Perhaps your role needs to know which method to call when it is done. Or what default value to use for its url attribute. Parameterized roles offer exactly this solution.

When using Moose::Role, a class which provides a method a role provides will silently override that method. This can cause strange, hard-to-debug errors when the role's methods are not called. Simple use MooseX::Role::Strict instead of Moose::Role and overriding a role's method becomes a composition-time failure. See the synopsis for a resolution.

MooseX::Role::WithOverloading allows you to write a Moose::Role which defines overloaded operators and allows those operator overloadings to be composed into the classes/roles/instances it's compiled to, while plain Moose::Roles would lose the overloading.