Tom Lanyon <[email protected]> writes: > On 09/04/2010, at 3:22 PM, Daniel Pittman wrote:
>>> http://search.cpan.org/~groditi/MooseX-Object-Pluggable-0.0011/lib/MooseX/Object/Pluggable.pm >> >> For what it is worth, when I had a similar set of needs, and a similar idea >> of how plugins would work to Dan, I tried MooseX::Object::Pluggable. >> >> It didn't do what I wanted especially well, for several reasons: >> >> It failed on point 1, since it didn't provide good mechanisms to enumerate >> and load all plugins, only to load named plugins. I ended up using >> Module::Find or so to locate all the bits of code. >> >> It failed on point 2, since it composed the plugins to my current instance, >> rather than letting me register them. This worked for some features, but >> poorly for others. > > I found the same, when I needed a factory-style plugin registry system, and > ended up building something custom which found and loaded all modules under > the MyApp::Plugin:: namespace and added them to a HashRef[MyApp::Plugin] > style attribute. > > I thought about making this a more generic solution but pondered whether > there was much benefit or whether most solutions for this would be > bespoke.... I think that there is a space for a framework that provided that sort of "load everything" model, and which allowed you to call "method X on all plugins", and "method X until a plugin returns a true value", since that covers the vast majority of needs. It also makes it easy to hook in more abstract negotiation mechanisms: call the "register" method in all plugins, passing a reference to your external negotiator, and use that to map back to them. Daniel Well, it would solve my problem, which is the same as "generic need", right? -- ✣ Daniel Pittman ✉ [email protected] ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons
