This module aims to allow `Dist::Zilla' to use plugins
using `Beam::Event' and `Beam::Emitter',
and perhaps reduce the need for massive amounts of composition and role application
proliferating `CPAN'.
This is in lieu of a decent dependency injection system, and is presently relying
on `Dist::Zilla' to load and construct the plugins itself, and then you just connect
the plugins together informally, without necessitating each plugin be specifically
tailored to the recipient.
Hopefully, this may also give scope for non-`dzil' plugins being loadable into memory
some day, and allowing message passing of events to those plugins. ( Hence, the `plugin:' prefix )
A Real World Example of what a future could look like?
[GatherDir]
[Test::Compile]
[Beam::Connector]
on = plugin:GatherDir#collect => plugin:Test::Compile#generate_test
`GatherDir' in this example would build a mutable tree of files,
attach them to an event `::GatherDir::Tree', and pass that event to `Test::Compile#generate_test',
which would then add ( or remove, or mutate ) any files in that tree.
Tree state mutation then happens in order of prescription, in the order given
by the various `on' declarations.
Thus, a single plugin can be in 2 places in the same logical stage.
[Beam::Connector]
on = plugin:GatherDir#collect => plugin:Test::Compile#generate_test
; lots more collectors here
on = plugin:GatherDir#collect => plugin:Test::Compile#finalize_test
Whereas presently, order of affect is either governed by:
=over 4
=item * phase - where you can add but not remove or mutate, mutate but not add or remove, remove, but not add or mutate
=item * plugin order - where a single plugin cant be both early in a single phase and late
=back
If that example is not convincing enough for you, consider all the different ways
there are presently for implementing `[MakeMaker]'. If you're following the standard logic
its fine, but as soon as you set out of the box, you have a few things you're going to have to do instead:
=over 4
=item ...