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 <>. 
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 

If any body is interested, here are my suggestions on PSR-14:


   - 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 
   - 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?


   - `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 
   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 post to this group, send email to
To view this discussion on the web visit
For more options, visit

Reply via email to