Re: Evolving roles and 3rd party modules

My first instinct is to do something like this:

package MyAPI::Version::One;
use Moose::Role;

require 'foo';
require 'bar';

package MyAPI::Latest;
use Moose::Role;

with 'MyAPI::Version::One';
[download]

This would mean that if a 3rd party dev wanted to support v1 then would make sure to do the MyAPI::Version::One role, and if they wanted to make the commitment to always stay on the bleeding edge they could do the MyAPI::Latest role.

Then when you update to a new version you simply do this:

package MyAPI::Version::Two;
use Moose::Role;
with 'MyAPI::Version::One'; # assuming back-compat
require 'baz';

package MyAPI::Latest;
use Moose::Role;

with 'MyAPI::Version::Two';
[download]

And then all 3rd party devs who were doing the MyAPI::Latest would have to be sure to update but those who did the MyAPI::Version::One role would still be safe and could upgrade to MyAPI::Version::Two when they are able to.

This should still be workable when you break back-compat too since there is no strict requirement that the MyAPI::Version::Two does the MyAPI::Version::One role.

-stvn

Comment on Re: Evolving roles and 3rd party modules Select or Download Code

Replies are listed 'Best First'.
Re^2: Evolving roles and 3rd party modules by dgaramond2 (Monk) on Apr 15, 2010 at 01:58 UTC
Thanks for the suggestion. Yup, adding version to role's name surely came to mind, though probably not really preferred in my particular case because I want to do incremental/continuous improvements to the role. The role here functions not so much as a strict interface but only as a warning mechanism for module developers about new methods. I was hoping for some button or configuration in Moose that makes roles less strict (e.g. warn() instead of die() when a required method is missing). I guess no one else would need or like such a feature?	[reply]
Re^3: Evolving roles and 3rd party modules by stvn (Monsignor) on Apr 15, 2010 at 14:16 UTC
I was hoping for some button or configuration in Moose that makes roles less strict (e.g. warn() instead of die() when a required method is missing). I guess no one else would need or like such a feature? Nope, we shun those kinds of ideas in Moose. The features are all there for a reason and often times other elements of the system rely on them working to provide the entirety of the given functionality. That said, Moose does provide a lot of meta-layer hooks and extension points so it might be possible to make a "soft" role like what you describe as a MooseX:: module. Depending on how you are using this role you might want to just think about plain old duck-typing instead. If you never provide implementation in the role then the Moose:Util::TypeConstratins duck_type() feature may be enough for your needs. -stvn	[reply]