I would recommend that setParam or indeed any setting of properties be out of the spec. In my opinion, Events and Commands should both be immutable, but people are open to implement configuration post-construction if they wish. But if the spec defines these, then the spec is defining the payload of them as mutable. That doesn’t strike me as a good idea.
-- Barney Hanlon On 13 March 2018 at 09:04:44, Xedin Unknown (xedin.unkn...@gmail.com) wrote: > 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 a topic in the > Google Groups "PHP Framework Interoperability Group" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/php-fig/EwCZ9ritJcA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > php-fig+unsubscr...@googlegroups.com. > To post to this group, send email to php-fig@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/9f44f49e-9f55-42e5-b8df-aee93c874007%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/9f44f49e-9f55-42e5-b8df-aee93c874007%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CALKGMgdqKm%3Dmy2q3SXxE5kV%2BN9FAbgS2suE2nEmdiLZhH9X-KA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
