IMHO, looks like we are nowhere with the event manager standard. There are a handful of implementations, most very recent. Not aware of any consumers, besides my code.
I believe there are many things wrong with that standard. Right now, I'm working on a proposal of how it can be changed. Meanwhile, I am maintaining the interfaces in dhii/psr-14 <https://packagist.org/packages/dhii/psr-14>. Currently super tied down with time. So much so, in fact, that I have not had any chance to work on the standard, which I am a part of the workgroup for. If any body is interested, here are my suggestions on PSR-14: EventInterface - Add `setParam()`. It is super common that parameters are set one at a time, by name. Right now, they must be set altogether, which is extremely inconvenient. - Add `hasParam()`. This can allow the consumer to determine whether something is indeed set. - Document what happens with `getParam()` if the param is not set. - Remove `setName()` and `setTarget()`. After an even is created with a particular name and target, nothing should be able to change this. Just imagine that the name is changed after the event has been dispatched. This is nonsensical. - (Optional) Remove `setParams()` and `getParams()`. The event should probably allow operations on one parameter at a time, similarly to `ContainerInterface`. Allowing *all* params to be retrieved is not practical, as it would in many cases require the map to be iterable. This is a burden on the implementation. If there needs to be an iterable list of something, it can be passed safely as one of the parameters. - (Optional) Remove `getTarget()`. Why does there need to be a target? Or maybe, a more appropriate name for it is "source", as this is the context that the event comes *from*. If it needs to be passed, and is optional, why not just have it be one of the parameters? EventManagerInterface - `trigger()` to accept only `EventInterface`, and not `string`. Why is it the concern of the event manager to normalize strings into events? This will make the logic simpler. - Remove `$argv` parameter from `trigger()`. If only `EventInterface` instances can be passed, this becomes redundant. Also, currently it is not documented what to pass in this parameter. - (Optional) Remove `$priority` parameter from `attach()`. With events, it is never clear what context this has. Priority as compared to what? How can it be possible to know what the other events' priorities are, so that I can put my event between them? This is a job for a module <https://github.com/RebelCode/module-interface/blob/develop/src/ModuleInterface.php> standard, which I happen to be working on. @Barney, get in touch if you wanna help make a draft. On Tuesday, August 15, 2017 at 11:12:48 PM UTC+2, Barney Hanlon wrote: > > Hello all, > > and in my first post in this group, I thought I might query where we are > at with event managers (PSR-14). > > Recently, forgetting to check the FIG site, I hadn't realised there was > already work on this and had started work on my own implementation of an > Event-based standard, so that all listeners/events/dispatchers/emitters can > play nicely. Obviously, far happier to go with an existing trend than try > and reinvent a wheel. However, I'm not sure how to contribute in any way as > a newbie to the mailing list. > > I was inspired to sign up because I thought it would be good to debate > further was the setParam() in the proposal - should events be mutable after > instantiation, as part of the spec? > > Hoping to hear back and would love to assist in this proposal. > > -- > Barney > > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to email@example.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/9f44f49e-9f55-42e5-b8df-aee93c874007%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.