EventManager Draft

[Chuck Reeves]

Back at PHPTek, @crell asked if there were any ideas out there for new FIG standards. I came up with the idea of having an Event Manager Interface through FIG.  

I took a look at Symfony, Zend Framework 2 and Doctrine to see how they work then started an early draft. I made mention of it on twitter and started getting some feedback.  I figured I would start a conversation here to avoid the limitations of twitter and incorporate those ideas into the draft.  Here is the link to what I came up with so far: https://github.com/manchuck/fig-standards/blob/master/proposed/event-manager.md

The 1st reaction was with the use of getName.  Symfony 3 is moving away from using it in favor of using objects.   My initial thought for including getName in EventInterface, was to allow implementer to build an event using EventInterface and then pass that in to the EventManagerInterface::trigger 

I do not know of any other frameworks use an event manager out there.  I would appreciate any feedback on my initial draft as well as insight into other frameworks out there that use events. 

Thanks

[Jeremy Lindblom]

Seems interesting and something I've thought about as well. I'm not sure how well it will work out, but it's worth a shot. I'll take a closer look this week.

You should look at Guzzle's event system as well, if you are looking for more existing implementations: https://github.com/guzzle/guzzle/tree/master/src/Event

Does EventInterface need setters? Being able to change the event's data does not have any perceived value. Name, Target, and Params seem like they should be immutable.

-- Jeremy Lindblom

PHP Software Engineer, AWS

--
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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/afb79018-4226-4922-aeb6-0a000add585a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aaron Scherer]

In several of the symfony events, you are able to change the Response, I'd say it's important to be able to change event data. 

—
Sent from Mailbox

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/9E49AC8D-9651-48B8-A5D8-5F0A3A89F48F%40gmail.com.

[Larry Garfield]

Yes, there's a lot of valid use cases for writing data to an event, or more generally for returning data or aggregate data from an event listener.

Drupal has had an event system for years that we call the "hook system", although it's more generic, procedural, and somewhat AOP-y.  We do a LOT of things with it, rightly or wrongly. :-)  Among the general types of hooks we have:

- Info hooks: Big definition arrays, generally cached.  Most of these have been replaced in Drupal 8 with yaml files or annotations.

- Alter hooks: Usually, but not always, big nested arrays that get passed by reference to various functions to mess with them.  Kind of a cheap-ass Visitor pattern, I think.  Most info hooks have a corresponding alter hook.  We don't have a conceptual replacement for these yet.

- "True events": The more traditional "X just happened, anyone who wants to take other action go ahead".

And there's lots of in-betweens, like hook_node_update that happens when a node (data object) is being saved, at which point listeners could alter the node before it hits the DB or take some other action, or both.  They all use the same syntax so it's 1) Very flexible and 2) Very hard to document well. :-)

One discussion that has come up in Drupal is that the Symfony approach to defining a new event or registering a new listener is very "heavy"; a new event involves defining a new class, ideally a constant or two, and injecting a service.  A listener is, almost always, a subscriber class which means writing a new class, explicitly specifying what to listen to, registering a service, and setting up dependencies.  For developers used to "magic function name and it just works" that's a lot of extra overhead.  I think it's useful overhead myself but there are a number of key Drupalers that disagree and want a fewer-step "lightweight" version.  That's something to keep in mind.

Another existing event library:

https://github.com/igorw/evenement

And another concern to keep in mind:  On the one hand, using closures to register a listener is super-simple and easy.  For many cases it's the easiest way to do things.  On the other, that means re-registering them on every request.  A compiled option (which AFAIK no system has right now; certainly not Symfony) would be necessary for high-scaling of a very event-driven system.  (I come from Drupal. We will push *anything* to a high-scale state.  That's what we do. <g>)

--Larry Garfield

On 07/20/2014 05:54 PM, Aaron Scherer wrote:

[FGM at GMail]

One option which might be interesting to consider (I used it when writing
Heisencache) is the NodeJS event system
http://nodejs.org/api/events.html : it is fundamental in that
environment, so can provide interesting insights, with a point of view
slightly different from PHP, of course.

[Hari K T]

Aura does have one, but for the good or bad it is called Signal.

https://github.com/auraphp/Aura.Signal/#instantiating-the-signal-manager

[Hugo HAMON]

Hi all,

I'm really wondering what the real value of providing such a new common interface is. It really made sense for the PSR-3 LoggerInterface as logging is a feature we find in almost any web applications. But event management is not something you will find in many apps. Symfony, Doctrine and Zend Framework already have their own implementation that fit their needs. I could understand that this new PSR would make sense for people using both Symfony/Doctrine and ZF/Doctrine as those libraries have their own event management system. But apart from that, I don't see any points for making a common interface. Maybe there are I don't (fore)see yet...

If you start using one event management library for your application, are you suddenly going to decide to change it for another? Do you think mature frameworks like Symfony or Zend will want to update their codebase and change method signatures and calls everywhere? It will be a huge BC break.

In my opinion, it's the same debate than standardizing DI containers with a common interface. DI containers are very specific to frameworks at the beginning.

In the end, I'm not really in favor of it if there is no real reason or added value for a new common interface.

Hugo Hamon.

--

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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/afb79018-4226-4922-aeb6-0a000add585a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

 

-- 
Hugo HAMON
http://www.apprendre-php.com

[Paul Dragoonis]

Hi Chuck,

This has been raised a few times. My take on this still stands when evaluating if a PSR should be started.

Q: Is this solving a problem that exists between library vendors?

On this occasion I don't think it does, I don't see any friction between event management library vendors.

If someone can show me evidence that this a problem then I will happily contribute my time towards an Event Manager PSR.

Many thanks,

Paul

--

[Lukas Kahwe Smith]

On 21 Jul 2014, at 10:39, Paul Dragoonis <drag...@gmail.com> wrote:

> Hi Chuck,
>
> This has been raised a few times. My take on this still stands when evaluating if a PSR should be started.
>
> Q: Is this solving a problem that exists between library vendors?
>
> On this occasion I don't think it does, I don't see any friction between event management library vendors.
>
> If someone can show me evidence that this a problem then I will happily contribute my time towards an Event Manager PSR.

Well Symfony2 and Doctrine tried to come together on a solution. In the end Symfony2 needed more flexibility while Doctrine needed more performance for some of their specific use cases which could not be reconciled into a single lib. But it might be possible to reconcile it under a common interface allowing users to then make certain choices for their use cases that might be different than Symfony2 or Doctrine.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

[Paul Dragoonis]

It may be likely that the use cases for event management are very specific (perf vs flexibility vs <insert use case here>) and there isn't room for common ground at the interface level. I'll back this PSR if there is common ground.

[Kayla Daniels]

For reference, This is the event library used by Laravel. 
https://github.com/Illuminate/Events

Another one, which is framework agnostic: 
https://github.com/heybigname/event-dispatcher

[Paul M. Jones]

Hi all,

> I do not know of any other frameworks use an event manager out there. I would appreciate any feedback on my initial draft as well as insight into other frameworks out there that use events.

There's always the Aura.Signal package:

<https://github.com/auraphp/Aura.Signal>


--
Paul M. Jones
pmjo...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
http://mlaphp.com

[Paul Dragoonis]

I've noted about 6 individual libraries then, a few frameworks and a few independent libraries.

The next thing FIG need to know is: are the maintainers of these libraries willing to ensure that their event managers meet PSR standards, even if it means aliasing things like 'getName()' to 'getMemberName()' or something like that.

--
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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/EE8D703E-5D16-471E-B1B1-67166103DA32%40gmail.com.

[Chuck Reeves]

Maybe there should be a couple of event interfaces then:

EventInterface - Follows the "True Event" you mentioned

AggregateEventInterface - Allows modification of the event response.  

If we go with this then should there be an EventResponseInterface that handles how get data out of the response?

[Alexander Makarov]

If ensure means break backwards compatibility then the answer is most probably "in next major release". Also it may not fit the needs as was noted before i.e. simpler event handling is OK for the library or even preferred for performance reasons.

[Marco Pivetta]

Hey Manchuck,

Is there already a PR for this suggestion? I honestly can't do much on the ML thread, but I'd gladly provide feedback on the diff itself.

As for the current state, I really like the idea of having a minimum common denominator of event managers!
The interfaces as they stand are a bit sloppy (mutability, mainly), but it's a good start :-)

Marco Pivetta

http://twitter.com/Ocramius     

http://ocramius.github.com/

[Larry Garfield]

I can't guarantee Drupal's response with our schizophrenic consensus
decision making process, but in general I think we're likely to follow
Symfony's lead at least in the near to mid term. IE, if Symfony
EventDispatcher adopts a PSR event interface we likely will stick with it.

The bigger use case, I think, would be for Guzzle, Doctrine, and other
stand-alone libraries to have a common way to trigger events.
Replicating Symfony EventDispatcher is probably not viable. Building
something to make it easy for Guzzle, Doctrine, etc. to bridge into
EventDispatcher (or Zend's, or Aura's, etc.) sounds like it would be the
more productive approach, and consistent with how we've approached
PSR-3, PSR6, and PSR-7.

--Larry Garfield

On 7/22/14, 3:53 AM, Alexander Makarov wrote:
> If ensure means break backwards compatibility then the answer is most
> probably "in next major release". Also it may not fit the needs as was
> noted before i.e. simpler event handling is OK for the library or even
> preferred for performance reasons.
>
> On Monday, July 21, 2014 6:03:59 PM UTC+4, Paul Dragoonis wrote:
>
> I've noted about 6 individual libraries then, a few frameworks and a
> few independent libraries.
>
> The next thing FIG need to know is: are the maintainers of these
> libraries willing to ensure that their event managers meet PSR
> standards, even if it means aliasing things like 'getName()' to
> 'getMemberName()' or something like that.
>
>
> On Mon, Jul 21, 2014 at 2:43 PM, Paul M. Jones <pmjo...@gmail.com
> <javascript:>> wrote:
>
> Hi all,
>
> > I do not know of any other frameworks use an event manager
> out there. I would appreciate any feedback on my initial draft
> as well as insight into other frameworks out there that use events.
>
> There's always the Aura.Signal package:
>
> <https://github.com/auraphp/Aura.Signal
> <https://github.com/auraphp/Aura.Signal>>
>
>
> --
> Paul M. Jones

> pmjo...@gmail.com <javascript:>

> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> http://mlaphp.com
>
>
>
> --
> 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+u...@googlegroups.com <javascript:>.

> To post to this group, send email to php...@googlegroups.com

> <javascript:>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/EE8D703E-5D16-471E-B1B1-67166103DA32%40gmail.com

> <https://groups.google.com/d/msgid/php-fig/EE8D703E-5D16-471E-B1B1-67166103DA32%40gmail.com>.

> For more options, visit https://groups.google.com/d/optout

> <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+u...@googlegroups.com

> <mailto:php-fig+u...@googlegroups.com>.

> To post to this group, send email to php...@googlegroups.com

> <mailto:php...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/b1ef43e5-a2e1-4a78-a79c-c2789ca62204%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/b1ef43e5-a2e1-4a78-a79c-c2789ca62204%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Dowling, Michael]

Even if an event system PSR passed (which I hope one does not since this
is way too application specific IMO), I still wouldn¹t be motivated to
break my users to update Guzzle¹s event system.

--Michael

>email to php-fig+u...@googlegroups.com.
>To post to this group, send email to php...@googlegroups.com.

>To view this discussion on the web visit

>https://groups.google.com/d/msgid/php-fig/53CEA7FF.2030409%40garfieldtech.
>com.

[Chuck Reeves]

I created PR 308

https://github.com/php-fig/fig-standards/pull/308

[guilher...@gmail.com]

Why not:

http://us.php.net/manual/en/class.splsubject.php

http://us.php.net/manual/en/class.splobserver.php

???

--

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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/154917c7-d4e0-4f09-898b-60178a95a78d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Guilherme Blanco
MSN: guilher...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

[Mike Willbanks]

Hello,

On Wednesday, July 23, 2014 9:48:50 AM UTC-5, Guilherme Blanco wrote:

Why not:

http://us.php.net/manual/en/class.splsubject.php

http://us.php.net/manual/en/class.splobserver.php

???

IMO subject and observer solve many concerns but it lacks in a variety of others. 

I'll hit on a few of them but you will not have to look far to see where the concerns start to hit with subject / observer.  This is a highly abbreviated list but yet it remains.

* Multiple Listeners (if you have them then you have to start aggregating them)

* Short Circuiting (Not currently possible without custom implementation) 

* Priority Queuing (Can semi-achieve with SplStack but results have varied)

There are tons of other use cases and far reaching ones as well.  I just don't think the spl subject / observer classes get you further enough down the road.

[Mike Willbanks]

On Tuesday, July 22, 2014 5:22:10 AM UTC-5, Marco Pivetta wrote:

Is there already a PR for this suggestion? I honestly can't do much on the ML thread, but I'd gladly provide feedback on the diff itself.

As for the current state, I really like the idea of having a minimum common denominator of event managers!
The interfaces as they stand are a bit sloppy (mutability, mainly), but it's a good start :-)

I agree a common denominator for the event managers would be great; I think even more so than that would be describing the event itself.  My personal take is I'd love more things to be emitting events; but that is more of a concern for the PHP language.

In terms of PHP-FIG; an attempt for a common interface may aide in application developers to integrate with other libraries. However, I do not see this being as beneficial unless there is a common event manager amongst all implementations.

Furthermore, event managers can range wildly in performance, flexibility, references, reuse and more.  For instance, if you decide to put heavy load on an event manager in say ZF2; your app will now be slower than molasses.   So now the implementation has to vary in order to speed it up and allow for common items.  But then you want more flexibility with wild card support, and it's a single small operation you'll likely never notice the difference.

Case and point, utilizing events for say when a property changes in an entity has to be insanely quick; vs. a dispatching of a single route, flexibility for middleware will prove to be a larger concern.  All of this to say; that the methods could be as simple as the spl subject and observer like Guilherme mentioned; or you end up with a highly bloated event manager that will be a pain to implement and likely slow.

Then as others have stated; how are you to separate the concerns of mutability vs. immutability.  When can a listener be attached and detached, is there even listeners?  Is it just a callback or an implementation of an interface?  How do you handle returns; is it aggregated or merged or does it change the parameter stack?  If you allow for parameters to be changed; are the parameters passed by reference or not?  (leading into previous question).

I commend the effort on this; but I really do not think a common interface would have a possibility of being remotely successful where everyone can find a degree of comfort.  Then at that point we are back to spl subject and observer which exists in core; has little to no functionality and everyone is going to do something different.

[Dracony]

I don't like that event target might be a string, usually those are object. Is there some proper use case where having a string would be more appropriate than an object ?

Also, perhaps it might be a nice idea to make events immutable-ish by removing setName() and setTarget() methods ? Manipulating those during an events lifecycle is a very sure way to event hell. Imagine trying to find the source of an event that changes its name a number of times during handling. I would also argue that modifying event params is also a bad practice.

[Rasmus Schultz]

I also like objects - I like type-hinted code that lights up green in an IDE very much.

Just to demonstrate how completely different event systems can be, take a look at this:

https://github.com/mindplay-dk/funnel/blob/master/example.php

I doubt you'd be able to reference this for anything at all, but just to demonstrate that there are radically different approaches to events :-)

[Dracony]

Perhaps if some projects really need the mutable event functionality we could have 2 standards with one extending the other (like PSR-1 and PSR-2) . One standard would define immutable events and the other one would build upon that one and add mutators to them. This way you would get the best of two worlds

[Javier Aguilar]

I understand your point of view, but sometimes you want to use packages instead of full frameworks to build your own lightweight framework that fits your needs for your project. I usually reuse libraries and/or components from other frameworks and one thing that I really miss is a common standard for Events.

That will open the door to new or existing libraries to adopt the new PSR and then people like me that don't use full frameworks could integrate a library that's interoperable with others following this PSR, so if one does not fit my needs I could switch to another quickly.

That is the value for me of having Events as a PSR, which is (in my opinion) one of the essential parts of modern web development.

Regards,

Javier Aguilar

[Javier Aguilar]

Hi all, is the PSR for Events still being considered (here or in another thread) ?

I find it as essential as PSR-7, IMO.

Thanks

Javier A.

mjolnic.com

[Michael Cullum]

Should someone wish to pick this up as Editor (An Editor doesn't have to be a project representative) and they can find a coordinator and sponsor (two voting members) to support the application then this could certainly head towards an entrance vote.

--

Michael C

--

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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/181b5caa-557b-419c-b361-b31cefdecb56%40googlegroups.com.

[Roman Tsjupa]

I can be either coordinator or sponsor for this one if you like.

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/-EJOStgxAwY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAqcDMiTYZYPN-usGDmThk_SsAZrY4bKrmeWXv_PZ2YLt-M%2Big%40mail.gmail.com.

[Brian Retterer]

Sorry... Realized I had two thoughts merged into one.

I would be happy to be a help with either as well (sponsor or coordinator)

However:  I am officially putting my name in as a sponsor for this.

Brian Retterer

Stormpath PHP SDK

On Wednesday, March 16, 2016 at 2:30:06 PM UTC-4, Brian Retterer wrote:

I would be happy to be a part of this either as well.

I officially put my name in as a sponsor for this.

Brian Retterer

Stormpath PHP SDK

[Michael Cullum]

I believe you have your team with the three of you then.

The next stage for a PSR is to put it to an entrance vote, by which point you just have to have your meta document with some goals/rationale laid out (I'd suggest looking at other PSRs for an idea of what kind of things are to go there) and you need to work out which of two of you [Brian and Roman] should be taking on the role of coordinator and sponsor.

For more information you are of course welcome to ask myself (I'm always available for a chat on IRC or on google hangouts), another FIG secretary or another (current or former) PSR Editor for advice and there is the workflow bylaw which explains the process well.

--

Michael C

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/0a16afb6-dc25-4ed6-8f14-c0cc8ab0d911%40googlegroups.com.

[Brian Retterer]

Roman,

Not sure how much time you have on this, but I am happy to take lead on this one and be named as coordinator if you want.

-Brian

[Larry Garfield]

My plate is full enough at the moment that I shouldn't have an official
role, but +1 on the concept. :-) I'm happy to help as I can; having
dealt with Drupal doing extension points in 3 different ways now (2 of
them event-ish), I've got some background to offer.

On 3/17/16 4:16 PM, Brian Retterer wrote:
> Roman,
>
> Not sure how much time you have on this, but I am happy to take lead
> on this one and be named as coordinator if you want.
>
> -Brian
>
> On Wednesday, March 16, 2016 at 2:52:04 PM UTC-4, Michael Cullum wrote:
>
> I believe you have your team with the three of you then.
>
> The next stage for a PSR is to put it to an entrance vote, by
> which point you just have to have your meta document with some
> goals/rationale laid out (I'd suggest looking at other PSRs for an
> idea of what kind of things are to go there) and you need to work
> out which of two of you [Brian and Roman] should be taking on the
> role of coordinator and sponsor.
>
> For more information you are of course welcome to ask myself (I'm
> always available for a chat on IRC or on google hangouts), another
> FIG secretary or another (current or former) PSR Editor for advice
> and there is the workflow bylaw

> <http://www.php-fig.org/bylaws/psr-workflow/> which explains the

> process well.
>
> --
> Michael C
>
> On 16 March 2016 at 18:32, Brian Retterer <bret...@gmail.com

> *
> *
> *Javier A.*
>
> mjolnic.com <http://mjolnic.com>
>

--
--Larry Garfield

[Brian Retterer]

Thanks, Larry.

I have started working on the initial Docs so I can make an official Entrance Vote

-Biran

[Javier Aguilar]

I am happy to see that this PSR is still being considered and you took the initiative. I would be happy to collaborate with the repository with PRs and feedback.

-- Javi

[Chuck Reeves]

Javi,

Im excited for the help.  I think the big block for this draft, is coming up with the best way to implement.  I started this thread to get some feedback on an EventManagerInterface.  We seem to be stuck on some of the details (should we create an event object that gets passed around, should we allow events to be stopped etc)  Any use cases that you can think of, will help with the decision making process.  Also any feed back on the current draft that exists now would also be appreciated.

[Larry Garfield]

Reminder: Do not wait for all details to be fleshed out before asking
for an entrance vote! It is counter-productive to do so as you get no
visibility at all from it. Just get a basic skeleton and mission
statement in place, get your working group together, and go for an
Entrance Vote.

Once you pass an entrance vote, we can setup a FIG mailing list etc. so
that it's easier for people to get involved who are interested, or just
want to know how things are evolving.

> --
> 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+u...@googlegroups.com

> <mailto:php-fig+u...@googlegroups.com>.

> To post to this group, send email to php...@googlegroups.com

> <mailto:php...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/064ea303-dce9-4c81-9bcb-f658cdab3817%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/064ea303-dce9-4c81-9bcb-f658cdab3817%40googlegroups.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.

--

--Larry Garfield

[Brian Retterer]

Larry,

I was waiting for it to be fleshed out a little bit more before doing the vote.  

-Brian

[Larry Garfield]

People voting on the Entrance Vote should *not* be looking at the
specific details of interfaces that are fleshed out. An Entrance Vote
comes down to, really, "do we want an event PSR, and are we OK with this
person as the Editor"? Nothing more. *All* code is, technically
optional for an Entrance Vote.

I will follow up later with a broader email, because there's a couple of
groups taking this approach and I think it's actually very
counter-productive and harmful. :-(

> > an email to php-fig+u...@googlegroups.com <javascript:>
> > <mailto:php-fig+u...@googlegroups.com <javascript:>>.

> > To post to this group, send email to php...@googlegroups.com

> <javascript:>
> > <mailto:php...@googlegroups.com <javascript:>>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/php-fig/064ea303-dce9-4c81-9bcb-f658cdab3817%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/064ea303-dce9-4c81-9bcb-f658cdab3817%40googlegroups.com>
>
> >

> <https://groups.google.com/d/msgid/php-fig/064ea303-dce9-4c81-9bcb-f658cdab3817%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/php-fig/064ea303-dce9-4c81-9bcb-f658cdab3817%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>

> > For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
> --

> --Larry Garfield

>
> --
> 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+u...@googlegroups.com
> <mailto:php-fig+u...@googlegroups.com>.
> To post to this group, send email to php...@googlegroups.com
> <mailto:php...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/60dfc145-fbff-4604-b491-214435cdc534%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/60dfc145-fbff-4604-b491-214435cdc534%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Joe Ferguson]

Hello all,

Just a reminder that the Entrance Vote for Event Manager is open in the voting thread: https://groups.google.com/forum/#!topic/php-fig/MFL__YvumkE

Thank you to all the Member Projects that have already voted. Those that have not yet voted please do so at your earliest convenience as voting will close 30/04/2016 at 16:20UTC.

Results so far:

Number of Non-Voters:    19

Positive Votes:    26

Negative Votes:    0

Abstain Votes:    0

Voters:    26

Total Number of Members:    45

Quorum Number:    15

Quorum Met:    Yes

Percentage Voted:    58%

Percentage of Voters Positive:    100%

Percentage of Voters Negative:    0%

Percentage of Members Voted Positive:    58%

Percentage of Members Voted Negative:    0%

Sponsor:    Brian Retterer

Secretary:    Joe Ferguson

Finish Date:    30/04/2016 16:20UTC

Passing (Over 50% of cast votes & Quorum):    Yes

Over 50% of Members Voted Positive:    Yes

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/570E658B.1090900%40garfieldtech.com.

For more options, visit https://groups.google.com/d/optout.

--

- Joe Ferguson
JoeFerguson.me
MemphisPHP.org

[Joe Ferguson]

Hello everyone,

Voting Thread: https://groups.google.com/forum/#!topic/php-fig/MFL__YvumkE

We currently have 64% of eligible voters that have voted. I'd love to have the remaining 16 votes cast. If you are a voting member that has not voted because you have no opinion, please vote 0 for abstention. 

Results so far:

Number of Non-Voters:    16

Positive Votes:    29

Negative Votes:    0

Abstain Votes:    0

Voters:    29

Total Number of Members:    45

Quorum Number:    15

Quorum Met:    Yes

Percentage Voted:    64%

Percentage of Voters Positive:    100%

Percentage of Voters Negative:    0%

Percentage of Members Voted Positive:    64%

Percentage of Members Voted Negative:    0%

Sponsor:    Brian Retterer

Secretary:    Joe Ferguson

Finish Date:    30/04/2016

Passing (Over 50% of cast votes & Quorum) Yes

Over 50% of Members Voted Positive:    Yes

Thank you for your time.

[guilher...@gmail.com]

I haven't discussed with all Doctrine members, but if I don't have time to do it, I'll leave my preliminary vote: +1 for the entrance vote, not for the PSR per se (I saw a few "flaws" - mostly docs - that needs to be detailed in another email).

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CABj1BaZ-m5xJ7vFRPODgTWFk6Ey48Q%3DRWyJ%3DkXxRJe63eF%3D%2BkQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Guilherme Blanco

Lead Architect at E-Block

[Joe Ferguson]

Hello everyone,

Voting Thread: https://groups.google.com/forum/#!topic/php-fig/MFL__YvumkE

The Vote will be closing tomorrow, April 30th, 2016 at 16:20 UTC. If you have not yet voted please cast your vote at your earliest convenience before the vote closes. I would love to see the Percentage Voted even higher than the current 71%.

Thank you to everyone who has already voted.

Results so far:

Number of Non-Voters:    13

Positive Votes:    31

Negative Votes:    0

Abstain Votes:    1

Voters:    29

Total Number of Members:    45

Quorum Number:    15

Quorum Met:    Yes

Percentage Voted:    71%

Percentage of Voters Positive:    97%

Percentage of Voters Negative:    0%

Percentage of Members Voted Positive:    64%

Percentage of Members Voted Negative:    0%

Sponsor:    Brian Retterer

Secretary:    Joe Ferguson

Finish Date:    30/04/2016

Passing (Over 50% of cast votes & Quorum) Yes

Over 50% of Members Voted Positive:    Yes

Thank you for your time.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAFp73XuR70pfT%3Dydg13QyJm8f-sjA9H6A6znFH%3Dn0E4UYz1n1w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Xedin Unknown]

Hi,

There's a new thread here that addresses the current EventManager draft. In the thread, the OP asks a few questions, which I also would like to know the answer to.

[Xedin Unknown]

Particularly, I would like to know what $argv, the 3rd parameter to EventManagerInterface::trigger() is. If these are some kind of event arguments, then this is wrong, because the event object itself will contain the parameters.

Another point I would like to mention is that it could be useful for EventManagerInterface::attach() to return a manager-wide unique handler ID instead of just boolean true on success. This would make it at least potentially possible to detach anonymous handlers.

Also, a point in relation to EventManagerInterface::trigger(): I understand that the attached event handlers can simply modify the parameters of the event in order to have an influence on the logic which dispatched the event. If so, then why the requirement to return the result of last handler call, and if required, wouldn't it make sense to have that be the EventInterface object itself? In my code, I often do something like this, which is very convenient:

$someVar = $eventManager->dispatch(
    'event.name',
    [    // Event parameters

        'my_arg'    => 'asdasd',

        'some_var'  => '123123',

    ]
)->getParam('some_var');

This allows me to very cleanly pass a variable through a stack of handlers which may potentially modify it, and retrieve that value, all in "one line".

[Daniel Plainview]

My 2 cents about trigger() method in general: this method looks like a try to satisfy everyone,

but it makes the method vague and unclean. IMHO, it's better to stick to some very straightforward and unambiguous signature.

If you still want to make possible different parameters types, please, make several trigger methods, not a single one.

Another thing I'm not happy with is the event interface.

This interface means that caller in general is not framework-agnostic:

he has to create instance of some specific event dispatcher like Symfony's one.

I suggest to add Event class. In this case, caller can use (or extend) this class.

It doesn't conflict with fact that, for example, Symfony has own base class, 

you always can wrap your "real" event into Symfony-event: https://github.com/symfony/symfony/pull/18873

And the EventInterface can be dropped completely.

[Xedin Unknown]

Daniel,

Didn't understand about the event. I think the fact that there is an interface specifically makes it framework-agnostic: any framework can adapt their class to that interface, without using any specific implementation.

[Daniel Plainview]

> I think the fact that there is an interface specifically makes it framework-agnostic

Let's look at 2 cases:

1. Caller. When we need to dispatch/trigger an event. In order to do it, we need an event object and we either have to create own Event class or create instance of existing Event class like Symfony\Component\EventDispatcher\Event. The first option is slightly annoying thing. The last one doesn't make caller framework-agnostic.

2. Listener. If you want to have framework-agnostic listeners, you should type hint against an interface and lose readability, type hinting of event arguments. Otherwise, if you type hint against concrete class like ProjectWasClosed, you would have indirect dependency on something like Symfony\Component\EventDispatcher\Event.

And in general, one-to-one interface with value object is not a good idea. My point is that you can replace EventInterface with Psr\EventManager\Event class. In this case, ProjectWasClosed would inherit this class and listeners could type hint against framework-agnostic event.

[Daniel Plainview]

So my proposition is to:

* distinguish events and hooks;

* separate EventManagerInterface;

class Event

{

   // immutable (getters only)

}

class Hook

{

   // mutable (setParams, stopPropagation, ...)

}

interface EventDispatcherInterface

{

   /**

    * @return void

    */

   public function dispatch(Event $event);

    /**

    * @return Hook

    */

   public function hook(Hook $hook);

}

interface EventSubscriberInterface

{

   /**

    * @return void

    */

   public function attach(...);

    /**

    * @return void

    */

   public function detach(...);

    /**

    * @return void

    */

   public clearListeners();

}

final class PreResponseHook extends Hook { ... }
final class ResponseWasSent extends Event { ... }

// You are able to modify response in handlers

$hook = $this->eventDispatcher->hook(new PreResponseHook($response));

$response = $hook->getResponse();

$this->send($response);

// You are stating a fact, handlers can't do anything with response anymore

$this->eventDispatcher->dispatch(new ResponseWasSent($response));

[Daniel Plainview]

https://github.com/php-fig/fig-standards/pull/766

[Haridarshan Gorana]

Hi,

I was looking for actual/real implementation of this PSR 14 EventManager. As we were thinking to implement this in our product. Does anyone can suggest how to implement this. 

I've tried to implement the interfaces by own but m very much confused with Event implementing EventInterface and EventManager implementing EventManagerInterface.

[Larry Garfield]

Greetings.

The spec is still far too new and in flux for actual/real implementations to exist; it's too early to try to build it into a for-reals product, as it's likely to change considerably before it's finalized.  Trial implementations to see if it would actually work, however, are very much encouraged.

If you tried to implement it and ran into confusion, that's exactly the sort of feedback we'd want to hear!  What was confusing, why, what broke when you tried it, etc?

--Larry Garfield

--

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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/19b06d9c-8ced-4d15-b0c2-5320a3665aa9%40googlegroups.com.

[Daniel Plainview]

> The event name MUST only contain the characters `A-Z`, `a-z`, `0-9`, `_`, and '.'.

This restriction makes impossible to make event names coinciding with class names, e.g. "Acme\Foo\BarWasFixed". I really like this approach, because it doesn't allow to make ugly generic events like "ProjectEvent". Dev is forced to make new class for every new event: ProjectWasStarted, ProjectWasLocked, ...

> It is RECOMMENDED that words in event names be separated using '.' ex. 'foo.bar.baz.bat'

Although I don't like approach with separated event name, I think it doesn't take into account namespaced events like "acme.project.was.started". Is it really better than "acme.project_was_started"?

[Larry Garfield]

Thanks for the feedback.  Part of me is tempted to go the exact opposite direction and always use a class name as the event name, at which point the event name parameter is unnecessary.  As long as it has a common interface the dispatcher should be able to route it properly, and the listener(s) will obviously need to know how to work with that class type anyway.  I'm not actually certain that the separate event name provides much value.

Anyone else want to weigh in on that front?

Note: In Drupal we are using acme.project_was_started style event names quite a bit, as it differentiates between event namespace and multi-word event names.  (Obviously using just the class itself as the event identifier eliminates this problem, for better or worse.)

--Larry Garfield

On 06/10/2016 03:15 PM, Daniel Plainview wrote:

[Daniel Plainview]

> Thanks for the feedback.  Part of me is tempted to go the exact opposite direction and always use a class name as the event name, at which point the event name parameter is unnecessary.  

Just to clarify, I'm proponent of this as well. My message could confuse though. 

The thing is when the event name coincides with a class name, you are forced to make fine-grained events. And that's great.

In my practice, requirement of separate event name is annoying.

You should add constant in FooEvents class, and after that you should create class with exact same name.

And then you realize that you want to rename the event...

[Woody Gilk]

On Fri, Jun 10, 2016 at 4:01 PM, Larry Garfield <la...@garfieldtech.com> wrote:
> Thanks for the feedback. Part of me is tempted to go the exact opposite
> direction and always use a class name as the event name, at which point the
> event name parameter is unnecessary. As long as it has a common interface
> the dispatcher should be able to route it properly, and the listener(s) will
> obviously need to know how to work with that class type anyway. I'm not
> actually certain that the separate event name provides much value.

I agree with this point.
--
Woody Gilk
http://about.me/shadowhand

[Larry Garfield]

On the flipside, where this approach raises questions is around
inheritance. If a listener is registered for FooEvent events, and a
BarEvent is fired where BarEvent extends FooEvent, should that listener
be called? I can see a good argument both ways; it's something that
would have to be specified explicitly in the spec otherwise different
implementations would go different, thus incompatible, directions with it.

--Larry Garfield

[Daniel Plainview]

> BarEvent is fired where BarEvent extends FooEvent, should that listener 

> be called?

I'm not big fan of inherited events, but I think so. 

What's your argument(s) against this behaviour?

At least, it's not hard to implement.

[Larry Garfield]

On 06/11/2016 08:49 AM, Daniel Plainview wrote:
> > BarEvent is fired where BarEvent extends FooEvent, should that listener
> > be called?
> I'm not big fan of inherited events, but I think so.
>
> What's your argument(s) against this behaviour?
> At least, it's not hard to implement.

My internal dialog goes something like this:

A) Extending events is a very easy way to reduce code duplication; there
are also plenty of cases where an event is a special case of another.

D) Sure, but you can get the same code savings with traits. And
extending interfaces is a better way to indicate that special casing.

A) Consider Drupal's Entity API (basically it's ORM, though we don't
call it that). We have different Entity Types, each with a different
class, and then bundles of that type, which are just configuration
differences. Every entity instance is of a type/bundle. There are life
cycle events on them, and we have a separate event call right now for
"all entities" and "entities of just one type". So if we were to map
that into an all-classed-event-no-names model, we'd currently be doing:

class EntityInsertEvent {}
class EntityUpdateEvent {}
class NodeInsertEvent {}
class NodeUpdateEvent {}

public function insert(Entity $entity) {
$this->saveEntityToDb($entity);
$this->events->dispatch(new EntityInsertEvent($entity));
$this->events->dispatch(new NodeInsertEvent($entity));
}

(Note we're not actually doing that, it's much more involved and uses
our legacy hooks system; that's irrelevant for the moment.)

Wouldn't it be nice to instead have NodeInsertEvent extend
EntityInsertEvent, and then only fire a single event? You could then
listen to all entity insert events, or just to those involving nodes, by
picking which class to type hint on. (Nodes being one of our Entity
Types.) And you have only one dispatch, which is better for performance.

D) Maybe, but one thing the current model lets you do is always know the
order in which things are called.

A) Order should be controlled via an ordering mechanism of some kind; if
simple priority numbers isn't sufficient, build something more robust;
don't hack different event types for that.

D) You could also get some very weird side effects if you have a more
complex event hierarchy. Like, what happens if you have NodeInsertEvent
extends EntityInsertEvent extends EntityEvent extends DebuggableEvent
extends Event? What happens then? That could get very unpredictable
very fast, or impressively slow and unperformant.

A) Or very powerful. Depends on what you do with it. You have to trust
that people won't do stupid things with it.

D) And when in the history of the Internet has that ever worked out?

A) ... Touche...

D) And then, do you type against classes or interfaces in the
listeners? Which should be the trigger?

A) Um. That's a good question, I give you 3 guesses.

D) Well I... hey, wait a minute...

(My internal dialog has a snarky side.)

--Larry Garfield

[Daniel Plainview]

I don't like inherited events, because in most cases it's a false abstraction.

Developers sometimes want to reduce *seeming* duplication, not real one.

For example, $event->getUser() doesn't mean you should create UserAwareEvent or something like that.

DRY is not about reducing lines of code.

However, from dispatcher perspective I don't see reason why the event shouldn't be dispatched

if it listener expects subtype of it.

Furthermore, I think if listener is type hinted against an interface, dispatcher should trigger it too.

> $this->events->dispatch(new EntityInsertEvent($entity)); 

> $this->events->dispatch(new NodeInsertEvent($entity)); 

> Maybe, but one thing the current model lets you do is always know the 

> order in which things are called

In general case events order can't be guaranteed by having these 2 lines of code.

Events can be queued, for example, and consumed in different order.

> You could also get some very weird side effects if you have a more 
> complex event hierarchy

Just don't hold it that way ©

The same you can say about class inheritance in general.

[Alexander Makarov]

Using class names as event names could be OK but that would result in empty classes which aren't well received by framework users.

[Daniel Plainview]

How often do you encounter empty events?

[Alexander Makarov]

Pretty often if you mean events w/o much data

[Daniel Plainview]

We have different experience. I rarely see events without payload. Can you give some examples?

[Alexander Makarov]

1. "Before request" which is triggered before each request. Request object is global and could be obtained from service locator (yeah, I know it could be passed w/ event as well).

2. Same about "after request".

3. "After validate" triggered after form is successfully validated.

4. "Begin page", "end page" are triggered in a process of rendering template.

5. "Init DB" is triggered right after DB connection was made.

...

The difference there though is that in Yii events could be triggered on an object so the object itself provides context info.

[Daniel Plainview]

Honestly, it looks like design issues in Yii for me. This approach just makes them more obvious.

Request is global ... until you want to make sub-requests.

Connection is global ... until you have multiple connections.

...

[Alexander Makarov]

HMVC (sub-requests) was never a goal. Connection isn't global. Event is triggered on an AR object so you can get connection used by concrete record from the record object itself. Events design is different from the proposal, yes and I actually like simpler global events approach more. Just voiced the fact that data-less events are possible and it depends very much on system design.

[Daniel Plainview]

Still, I think your examples are too Yii-specific.

Just yet another thought: if you pull your request from service locator (Yii-specific?),

then you probably don't need framework-agnostic events,

because your event handlers are already have strong coupling with Yii.

The same I can say about active-record models.

[Alexander Makarov]

Yes, indeed Yii in its current state can't really be used from an app implemented using another framework (it's not a set of decoupled libraries) but other libraries are easy to use in Yii. That's why even if we won't ever decouple Yii more it could benefit from standardized events.

[Daniel Plainview]

Exactly. So let's return to the beginning of our discussion: events without payload. You don't need payload in most cases, because your event handlers are coupled with Yii, but how third party libraries are supposed to work with these events?

[Alexander Makarov]

If we're talking about global events i.e. no concept of calling an event ON concrete object then usually there's a context that's to be passed.

[Michael Cummings]

actual very easy to convert a namespace to event name with '.'
$eventName = str_replace('\\', '.', __CLASS__);
Same basic idea I use to convert namespaces into directory path parts for stuff.

[Michael Cummings]

My concern is that the EventInterface is much heavier then it needs to be. Just some of my thoughts on it:

There's really no need for the event to know what it's being called by anyone. The code that triggers the event names it, the listeners know which ones they want to attach to, and the Manager makes it happen. To make it easier for the listeners you have the name as a parameter to the callback so you can have a single callback method if you choose and route the handling internally if you want. This makes the event name immutable by default. If one of the listens what to format the context after doing something with it they just trigger their own event.

I don't really understand why it has setter/getter for any parameters either as anything you'd use them for should be part of the context.

The idea of have a standard way to access the context is great but misplaced IMHO. Just look as Docblock from getContext() ```@return null|string|object```
You might as well just used mixed at that point. The reason this is happening is anything about the context/payload of the message is going to be depend total on the domain it's used in for what is returned. once again the code triggering the event determines what this is and the attached listeners need to know how to work with it. We've all seen this before you need an interface here which probably already exist or should be defined. Something like MyAppEventInterface extends EventInterface comes to mind for me. That insures it can be past to the trigger() and the attach listeners can use either interface on the parameter in their callback as they need.

So with this changes the EventInterface becomes very simply and easy to implement:
```php

namespace Psr\EventManager;

/**
 * Representation of an event
 */
interface EventInterface
{
    /**
     * Indicate whether or not to stop propagating this event
     *
     * @param  bool $flag
     */
    public function stopPropagation($flag);

    /**
     * Has this event indicated event propagation should stop?
     *
     * @return bool
     */
    public function isPropagationStopped();
}
```

I use something very similar in my own event system I developed just with a little different names for methods etc.
PHP Event Mediator
 

[Michael Cummings]

I decided instead of making a bunch of different posts here with my ideas I'd just fork the fig docs and post a link and hopeful get some feedback and comments from people on the changes then look at doing a pull request afterwards any additional changes.
https://github.com/Dragonrun1/fig-standards/blob/master/proposed/event-manager.md

[Daniel Plainview]

Question to Dracony as the only active Sponsor of this PSR: what will happen next? What's the current state of this PSR?

On Thursday, March 10, 2016 at 1:42:19 AM UTC+3, Dracony wrote:

I can be either coordinator or sponsor for this one if you like.

On Mar 9, 2016 23:38, "Michael Cullum" <m...@michaelcullum.com> wrote:

Should someone wish to pick this up as Editor (An Editor doesn't have to be a project representative) and they can find a coordinator and sponsor (two voting members) to support the application then this could certainly head towards an entrance vote.

--

Michael C

On 9 March 2016 at 21:07, Javier Aguilar <mjo...@gmail.com> wrote:

Hi all, is the PSR for Events still being considered (here or in another thread) ?

I find it as essential as PSR-7, IMO.

Thanks

Javier A.

mjolnic.com

--
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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/181b5caa-557b-419c-b361-b31cefdecb56%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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/-EJOStgxAwY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAqcDMiTYZYPN-usGDmThk_SsAZrY4bKrmeWXv_PZ2YLt-M%2Big%40mail.gmail.com.

[Brian Retterer]

Hi Daniel,

As the current coordinator, I will be reaching out to the others on this PSR to discuss what we need to do next.  I apologize for the delay in my responses as it has been a very busy time for me. Please stand by for future updates.

-Brian

[hongz...@gmail.com]

Just noticed the PSR event manager proposal and took a look at it today. Frankly speaking, I was disappointed at its current achievement, consider it's almost 2 years for this thread. here are the questions I have regarding the PSR event manager proposal.

1. why not use 'detach($event, $callback = null)' to replace 'clearListeners()' ?

2. How to clear all events ? how about 'detach($event = '', $callback = null)' ?

3. $priority higher value means higher priority ? anything about its range ?

4. typo: detach()'s phpdoc  @param string $event the event to attach too ?

5. why no sanity checking on event name input ?  what if it is not valid, why not throw an expection ?

6. why no 'setParam($name, $value)', what if a handler want to set a single value ?

7. why no default value 'true' for public function stopPropagation($flag) ?

HZ

在 2014年7月21日星期一 UTC+8上午4:40:33，Chuck Reeves写道：

[Michael Cummings]

I like you, hongzh2002, I'm a little disappoint that this is been so slow in developing. If it had already been approved and implement by someone like Monolog did with PSR-3 I probably wouldn't have made my own. Making my own wasn't really a waste of time either for me as I learned a lot of things in the process but I could have used the time on other projects as well too.

Just a couple comments on your ideas about changes

 to consider hongzh2002. on 1 and 2 using null would be a bad idea because it would make it so one small typo goes from cause easy to catch errors or exception to trying to figure out why your events aren't being sent to the registered callbacks / handlers anymore. Given the syntax you proposed if I was try to just remove one listener like this 'detach($event, $calback);' I have a problem.

Did you notice the problem? instead of spelling it $callback with 2 Ls  it had one. PHP just trying to be helpful decides I want a new variable and give me one with a value of null. So now instead of removing one thing I could break everything. With the original proposed way of doing things most implementations are going to either log an error or throw an exception when it receives null instead of the expected callable. Another value that might be better in your proposed change is false instead which doesn't have the same hazards I just covered.

Personally I only see having the detach() and clearListeners() for completeness only, as once I attach() to an event I did so to receive all of them that come along until the whole process ends but I guess there might be a few cases where you only want to attach for the first one then detach etc.

3 I do think it needs to be settled on as well. The to ranges that come to mind for me would be that of an int with or without allowing negative numbers with larger numbers have the higher priority. Most existing implementation I've looked at use one of those ranges so for any that wanted to align with this PSR it would make doing so easiest to have the same range. The main question here is it a 32 or 64 bit int. I would say 32 bit is more than enough to require but allow implementation to extend to 64 bit if they want. That would allow anyone stuck with using 32 bit versions of PHP to use it but still allow more room for anyone else that thinks they really are going to be attaching more listeners then there are grains of sand on earth or stars in the universe ;)

4. I noticed too and I'm sure it's a cut and paste typo.

5. This is probably outside of the PSR as it's getting into the implementation details which shouldn't be included in one just like has been the case with all the PSRs. PSRs are meant to fully cover all implementation details they just set the minimum spec for inter-operation that everyone can use. Just like Monolog implements everything in PSR-3 but extends beyond it that would be expect here as well with the understanding that if you do use those things beyond the PSR you are binding yourself to a certain one and ignoring the reasons for the PSR to start with.

6. You have just made my point that by not having the payload be an object and having the additional things that can be added you are going down a slope that leads to lack of inter-operation that this PSR is trying to be solved. The payload needs to be a first class object to have any hope that different implementation can be dropped in to replace each other and all the other setters and getters dropped from it. I do understand for some people having to create yet other object just to pass a simple value seems like over kill but see it as more of a bad smell myself that you have a problem with you object structure if you are passing around a bare value with an event that needs to be fixed.

7. I agree having a default value of true makes sense here.

--

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/-EJOStgxAwY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/05d1ed4d-6670-4270-b10f-5e17655bb75b%40googlegroups.com.

[Daniel Bannert]

Hey, small question,

why $argv can be a object or array in trigger($event, $target = null, $argv = []) when eventinterface can only take array for parm?

[Benni Mack]

Hey Brian,

we're from TYPO3 (CMS) are currently overhauling our event system and are following the PSR quite closely, almost implementing it 1:1 for our CMS - however the stagnation of the PSR doesn't bring some confidence that this PSR is ever going to happen. However, we'd love to contribute in order to actually make it possible to have our Event system interchangeable with other systems.

Some remarks on the proposal:

* Should we give a range for the "priority" (0-100 ?) otherwise it feels like the HTML/CSS "z-index" which I just set to 4000 and will be higher than all the others - until another framework thinks the same ;) - This is a bit different approach than Michael's remarks, however it'd be useful have that cleared up.

* What happens if a listener adds itself to an event but an existing listener has the same priority? Is there an exception going to be thrown? Graceful "upping" or "downing" the priorities? First come / first serve? We should probably just have that cleared up and written down.

All the best,

Benni.

[Michael Cummings]

Most of the implementations I've seen call listeners in the order they are added when priorities are the same which is how I've also done it in my projects. The additional feature I've found useful is allowing 'first' and 'last' keywords for the priority when adding listeners but I'm not sure if that should really be in the PSR or not. I can see where depending on implementation figuring out and possibly having to reorder the listeners could be hard to do but if everyone likes the idea it might be useful. Just to make it clear the way I implemented it 'first' and 'last' are based on the state at the time the listener is being added and not when the event is called.

For example say there are already a couple of listeners with priorities of 10 and 20 and you use 'last' for another listener it will be given a priority of 21 and if you added another listener with 'last' it would end up with priority of 22 etc. If you then added one with 'first' it would be assigned 9. I use this to add default listeners for events while allowing users to add other listeners to override the defaults by adding them beforehand or using 'first' and choose to handle or not. By doing this the actual priority becomes mostly an implementation detail and I only need to worry about order things are added and not some random magic number 😋. The main thing is the PSR should allow as much flexibility it can while still being detailed enough to allow make sure implementations can be interchanged which is why I thought int was best as it should not cause any real limits for anyone.

--

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/-EJOStgxAwY/unsubscribe.

To unsubscribe from this group and all its topics, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/c4ccbc90-7358-42a3-905b-097b0da7d0a7%40googlegroups.com.

[Benni Mack]

Hey Michael,

thanks for the reply. OK. so just to understand - the intention of the "priority" is

"1" = first one

"2" = after that one

and not the listeners with the highest (e.g. 100) priority comes first? I think this should be clarified then.

I like the "first" and "last" idea, however, that makes the PHP code of the interface kind of "mixed" (allowing string and ints).

Should I add some remarks / examples of the priority topic to the proposal as PR?

All the best,

Benni.

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+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAP9GSfWYk0zabs9GOKUGpMWb3_vNvaGnDO8NxPp_0kyATqOYVw%40mail.gmail.com.

[Brian Retterer]

Hi Benni,

Thanks for reaching out.  I am going to get the team together and get working on this again in the next week.  I will have some more details for you then.

-Brian