[PSR-14] Meeting Summary - 2018-08-15

[Larry Garfield]

We had another good call with most of the Working Group present. This time we
went over several trial implementations that various Working Group members
have built, to varying levels of completeness. They're available here
(although their workingness at any given moment is not guaranteed, as the spec
evolves):

Larry: https://github.com/Crell/Tukio
Benni: https://github.com/bmack/kart
Cees-Jan: https://github.com/wyrihaximus/php-broadcast
Matthew: https://github.com/phly/phly-event-dispatcher

On the whole we're pretty happy with where things are, although we did come up
with a number of additional spec tweeks to make. The biggest is changing the
namespace of the package to Psr\EventDispatcher (rather than Psr\Event
\Dispatcher). We're going to continue to do another round of implementing; in
particular, Liz Smith is working on an event driven CLI app and Cees-Jan has
agreed to try a Promise-as-Event implementation to make sure it works. (It
should, but better to actually do it.)

We've also started building a util library to go along with the spec, which is
available here:

https://github.com/php-fig/event-dispatcher-util

Open questions are mostly around error handling minutia. The big one is
whether it's appropriate, inappropriate, or required to have an ErrorEvent
that is also itself an Exception, and thus can be thrown.

For those following along at home, the latest code for the spec interfaces is
here:

https://github.com/php-fig/event-dispatcher

And you should use the 0.4.0 tag for the latest version.

On the agenda for next time is what, if any, optional interfaces we include in
the util package for registering listeners in providers manually (which is the
most common case), and what they should support.

--Larry Garfield
PSR-14 Editor

[desig...@gmail.com]

I'm very curious to know if there was a particular reason why StoppableTaskInterface::isStopped() was not named StoppableTaskInterface::isPropagationStopped() ? 

The method description says "This will typically only be used by the dispatcher to determine if the previous listener halted propagation." -- so shouldn't "isPropagationStopped" make more sense here as the events down the chain would know that "event propagation" has been stopped?

[desig...@gmail.com]

Sorry, correction, I meant .. 

"... so shouldn't "isPropagationStopped" make more sense here as the dispatcher would know that "event propagation" has been stopped by the previous listener?"

[Larry Garfield]

Mainly because we didn't feel like typing a longer name, I think. Nothing
more deep than that.

That said, I checked and Symfony currently uses isPropagationStopped(). So we
may want to use the same to help with transitional code. I'll add that to the
agenda for our next call to discuss. Thanks for the catch!

--Larry Garfield

On Friday, August 24, 2018 8:10:09 PM CDT desig...@gmail.com wrote:
> Sorry, correction, I meant ..
>
> "... so shouldn't "isPropagationStopped" make more sense here as the
> dispatcher would know that "event propagation" has been stopped by the
> previous listener?"
>
> On Saturday, August 25, 2018 at 6:06:31 AM UTC+5, desig...@gmail.com wrote:
> > I'm very curious to know if there was a particular reason why
> > StoppableTaskInterface::isStopped() was not named StoppableTaskInterface::
> > isPropagationStopped() ?
> >
> > The method description says "This will typically only be used by the

> > dispatcher to *determine if the previous listener halted propagation*."

[desig...@gmail.com]

Great, thanks for looking into it. I have one more suggestion, isn't it better to rename "getListenersForEvent" to "getEventListeners" ?

[Matthew Weier O'Phinney]

On Tue, Aug 28, 2018 at 11:53 AM <desig...@gmail.com> wrote:

Great, thanks for looking into it. I have one more suggestion, isn't it better to rename "getListenersForEvent" to "getEventListeners" ?

I personally prefer the current naming ("getListenersForEvent()"), as it reads more like natural language. Additionally, `getEventListeners()` doesn't have the same implication that we are retrieving only the listeners for the specified event.

 

--
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/76f3484d-498c-433a-a71d-9b170d638404%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

[desig...@gmail.com]

Hi Mathew, 

I looked around for some existing implementations and found one that Chrome, Firefox and Safari support (for debugging purposes in their developer tools console):

    - https://developers.google.com/web/tools/chrome-devtools/console/command-line-reference#geteventlistenersobject

    - https://developers.google.com/web/tools/chrome-devtools/console/events#view_event_listeners_registered_on_objects

The implementation, however, is slightly different as the "getEventListeners" method does not take an event object as an argument, but elements the event is attached to, but perhaps, an existing implementation such as this could help look at things from a different angle? Here's an example:

var listeners = window.getEventListeners(document.body);
Object.keys(listeners).forEach(event => {
    console.log(event, listeners[event]);
});

Also, how about:

$listeners->getListenersByEvent($event);

There a few implementations out there using that too.