Beam::Emitter v1.004 Released
This week, I released a new version of Beam::Emitter. A lot has changed since the first releases, so here's some details on all the new features.
Beam::Emitter is a role for turning your classes into event emitters. Being an event emitter allows other classes to subscribe to important events from your object. Subscribers can use these events to perform additional tasks, transform your object's data, or otherwise extend and enhance your class. Beam::Emitter makes your class extensible by allowing you to provide specific places for custom code to run.
Since the 1.000 release last year, Beam::Emitter has gotten quite a few new features and bug fixes to make it easier to use and safer for your code.
Beam::Emitter now tracks listeners using a Beam::Listener object. You can also create your own custom objects for tracking listeners, which allows you to hang arbitrary metadata in your listeners.
Calling the
subscribemethod (or theonalias) to subscribe to an event returns a reference to a subroutine that, when called, will unsubscribe from the event. Using this subref makes it easier to avoid creating memory leaks through circular references when you want to unsubscribe from the event in the event handler callback.Beam::Emitter no longer pollutes your namespace with things like Scalar::Util::weaken and Carp::croak. This makes it less obtrusive, though your existing code might die if you were relying on this bad behavior by Beam::Emitter (#sorrynotsorry).
I want to thank Diab Jerius (with the Smithsonian Astrophysical Observatory), Kent Frederic, and Yanick Champoux for all their help that has gone in to this project.
I'd recommend extending the synopsis into something that actually does something sensible.
This primarily since i just spent 2 minutes skipping back and forth in the docs, and i still don't know why i would want to use this, or what problem it solves.
(Note that i'm not saying you should explain here, but that your docs are missing the answer to those two questions.)
Yeah, you've got a point. I should come up with some actual use-case scenarios, add them to the Cookbook, and then put one or two of them up in the SYNOPSIS. Thanks!
This looks really nice! Now I'm thinking of using it for a plugin system in a new project. :)
Small comment: It's using Types::Standard from Type::Tiny which seems abandoned. :/
Toby Inkster is 404, sure. I'm not sure that Type::Tiny is yet abandoned, but nobody has yet started the adoption procedure. It's in a similar limbo to how JSON::PP was/is... That said, if there's a Moo(?:se)?-cabal-approved replacement, I'm willing to go for it.
I just released 1.005 with an expanded SYNOPSIS and a modified DESCRIPTION to try to clarify how this all works. Does it make a little more sense now? https://metacpan.org/pod/release/PREACTION/Beam-Emitter-1.005/lib/Beam/Emitter.pm
Note: BPO doesn't notify commenters of responses to them.
As for the changes: If i read it in detail i might understand why it does, but what's still lacking is a simple sentence that does not answer the "what" or "how", but the "why", the motivation, the problem you set out to solve and wasn't solved well elsewhere yet. That would give others a motivation to read on and learn about the what and how.