I intend to publish a few roles as a specification for third party support modules, e.g.:
package ModuleSpec; use Moose::Role; requires 'foo', 'bar', 'baz', ... ...; # actually there are quite a lot of methods to require
The existence of module spec helps when developing a support module, by reminding developer what methods it should support.
However, in future releases I intend to incrementally update the spec by adding more methods. Yes, I know about API freezing and stable interface, but in my case the module spec is somewhat looser/less formal than an API specification, and most of the evolution will be new methods without affecting much of the old/existing methods.
I don't want third party developers to have to keep updating their modules whenever my module specification comes out and adds some new methods here and there. I want users to be able to use older support modules with the newer module specification role.
But I also like to keep this specification as a role to remind developers what methods are newly required, so they can update their module to reflect the new specification.
So, can I somehow make so that:
use AcmeSupportModule;
use Moose;
with 'ModuleSpec';
sub foo { ... }
sub bar { ... }
sub baz { ... }
...
when a method is missing/unimplemented, just emit a warning instead of failing to load the module.
Currently I wrap all 'requires' in ModuleSpec like this:
package ModuleSpec; use Moose::Role; use MyUtil; apifunc 'foo', ...; apifunc 'bar', ...; apifunc 'baz', ...; ...
and, depending on the situation, apifunc() will eval a 'requires "foo"' or just 'sub foo { ... }'.
Any better way to do what I wish with less hackery?
In reply to Evolving roles and 3rd party modules by dgaramond2
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |