Would You Find this Moose Role Useful?

I find as part of my normal course of writing perl moose based code, I do the following quite often:

Sample Gist

Basically I tend to use the above with a core application class that is delegating work to several other classes.  In the above case, my general Library Class contains a Album class (presumable your library would hold an album and perhaps several other things).  In my Application logic I'm going to be calling methods on Album which have been properly normalized to the class which attempt to encapsulate the problem domain it attempts to solve.

I find the above form, although a bit verbose, to give me a lot of flexibility, particularly when I bring the application model into Catalyst via something like Catalyst::Model::Adaptor, which let's me define all the args in the global catalyst configuration.  Also, for testing, it's nice to be able to override the default classes, swapping in say a Mock Object or similar for the purposes of test cases.

In general use this construct commonly to avoid hardcoding all the connections between the elements of my applications.

Usage might be like:

Usage

Although I as mentioned, typically I instantiate this via Catalyst or as part of a more complicated application using an inversion of control container like Bread::Board. 

However it can lead to a little too much verbosity in core application classes, particularly if I have a bunch of these.  It's a type of repeated line noise which hides the actual functionality of the class.  So I'm considering creating a Moose Parameterized Role to build these for me, something that would work like (as a minimal case):

Possible syntax

Useful?  What, if anything should I do to make this CPAN worthy?  Or are the requirements of this oft repeated task unique enough as to make a usable code generator unfeasible?  Or am I the only one doing this (I don't need vanity CPAN modules...)

If you say "Yes", you also owe me a reasonable name (naming things I am not good at...)

Comments

[Shlomi Fish]

Just a note - without JS turned on (from all the many sources on this page), your post contains a few empty spaces where the code should be present. Why couldn't you just use a plain PRE element (or whatever) for the code? It seems to be a github gist thing in your case, but it's an overkilll for that.

[John Napiorkowski]

I thought I'd try the gist, since it seems all the other kids are doing that in their blogs. But if it's barrier to communication I'll do something else next time. Thanks!

[mitsuko891]

this is cool

[nperez]

As confirmation to your idea, I've somewhat done this recently for work code. Things were config driven (though not Bread::Board, much simpler) and it cut out a lot of boiler plate code every time I wanted a class to be able to access the logger, for example.

[John Napiorkowski]

nperez: What I've been doing in the past is create a custom role for each class that could be 'aggregated' (not sure about the best term here), which did cut down on boilerplate line noise. Up until now that's typically what I did, just I've done maybe 20 roles like that and noticed redundancies. Would be great to see your version as I try to code up a generator. I'll try to put something on github later today for comments. Thanks for the feedback (and still looking for a name, right now it's "MooseX::Role::BuildAggregrateAttribute" although considering "MX::Role::BuildInstanceOf" as well. Not even sure this belongs in the MooseX:: namespace.

[speedy]

[this is good] but I confused right now