Re^2: Evolving roles and 3rd party modules

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?

Comment on Re^2: Evolving roles and 3rd party modules

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]