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, [email protected] 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*." > -- so shouldn't "isPropagationStopped" make more sense here as the events > down the chain would know that "event propagation" has been stopped? > > On Tuesday, August 21, 2018 at 3:23:14 AM UTC+5, Larry Garfield wrote: >> >> 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 > > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/bc4a4bd7-e372-4456-bdf9-5eea740c93b0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
