Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • So we already have a mechanism in place whereby extra parameters can be passed into a role during composition, see Recipie 11 [cpan.org] for an example of the features that utilize this. Basically anything that is not another string passed after the roles gets turned into params (rjbs++ for Data::OptList which basically does all that work for me). So your examples would basically turn into this:

    with 'My::Role'; ### no need to change this

    with 'MooseX::Log::Log4perl' => [ ':easy' ]; ### this might not exactly work, but perhaps this ...

    with 'MooseX::Log::Log4perl' => { mode => ':easy' }; ### or something similar

    with 'MooseX::Log::Log4perl' => { prefix => 'mylog_' }; ### this will just DWIM

    No need to add a new keyword/export either (something which I am extremely hesitant to do and should not be taken lightly).

    So, while all these args are passed into the role application already, there is no clear way to do anything with them yet. This is the first hurdle for parameterized roles, how and where are these parameters handled? We have the "alias" and "excludes" features in the core, these are borrowed directly from the original Traits paper and are important tools for role disambiguation if your in a pinch, but they are as much as I am willing to shove into the core at this point. What we need is a more general mechanism which can be used to implement your own parameters which can influence role application/composition. And this is where I stop, cause honestly, I am not sure what that is yet.

    - Stevan