On Thu, Jan 10, 2019 at 6:01 AM <[email protected]> wrote: > Glad to see this is in working mode again. >
As Larry noted, we have been diligently working all along; however, we had a lot of back and forth and discussion happening that precluded any changes to the interfaces. Once the discussions were resolved, we could report back again. There simply was no point in giving a blow-by-blow each week until decisions were made. > I would love to know if there are any other example implementations done > for the latest spec? Thanks! > Yes - https://github.com/phly/phly-event-dispatcher is the implementation I've been working on. I'm also planning on doing a patch against zend-eventmanager soon to detail one way we may be able to adopt it in a future release. On Thursday, January 10, 2019 at 10:13:58 AM UTC+5, Larry Garfield wrote: > > It's been a while since I've filed one of these, I'm afraid. Fall was a > mix > of deep discussion that wasn't complete yet, conferences and other > schedule > conflicts that slowed us down, and then the holidays. I didn't want to > present a discussion that was still actively engaged in sausage making and > still subject to active change on a moment's notice, so, well, here we > are. > However, I'm going to try and summarize the various changes we've made to > PSR-14 in the last few months now that we're settled down again and, I > think, > in a very good place. This summary is not chronological, but in the order > I > think makes the most sense collectively from our last update. > > * After a great deal of discussion, we decided to remove the > Message/Notifier > portion of the spec. In the end, we decided that there just wasn't enough > existing prior art for us to analyze and determine good edge case handling > for > that approach. In particular, our nominal target for that pathway, > Symfony's > Messenger component, on further review we determined to be a completely > different use case anyway that was not even what we were targeting here, > and > thus irrelevant to PSR-14 entirely. > * That in turn allowed us to remove several nouns from the spec (yay), > which > meant that we could fold the "Event" term back into the only "thing that > gets > passed". The "Task" terminology is now gone. There's just Events, > Dispatchers, and Providers. > * However, after looking into Laravel in more detail and examining the way > Listener callables and Providers were defined already, we realized that > the > bulk of the use cases for Messages -- that is, potentially deferrable/ > asynchronous unidirectional communication -- could be handled in a similar > fashion to Laravel's "ShouldQueue" marker interface on the *listener* (not > the > event). Specifically, listeners are abstractly defined enough that they > can > still defer actions themselves, or Providers can add a deferring wrapper > themselves, in appropriate situations. That is, we can cover just as many > use > cases as before but in a more flexible way with less ceremony. > * With the simplified set of interfaces, there is now little value to the > marker interface as there would be only one. However, we still wanted to > provide at least some level of type safety as that is a key component of > any > specification. To that end, we have removed the EventInterface marker > type. > * However, we have replaced it with an "object" type hint. That in turn > necessitates increasing the version requirement to PHP 7.2. This was a > difficult decision, but in the end we decided that it not only made the > spec > better but it *improved* backward compatibility for existing > implementations > thanks to PHP 7.2's allowance to drop type hints in subclasses; that > allows > existing implementations (in particular Symfony and Laravel) to support > both > PSR-14 and their current APIs in parallel without a syntax violation. We > also > determined that, at least within the expected release schedules of Symfony > and > Zend Framework, a PHP 7.2 requirement is only a minor delay in their > ability > to implement the specification. Given that many previous specifications > have > been hindered by targeting "in the wild but soon to be deprecated" PHP > versions that limited their ability to leverage new language features, we > determined that the specification was best served by targeting the > already- > legacy PHP version rather than a version that is already only barely > supported. > * Because of all of the above, we were also able to collapse the spec back > to > a single composer package rather than the previous 3, which is always a > win. > > The specification text is now up to date, modulo a few bits of fiddling > we're > still working on that shouldn't have any impact on the interface > signatures > themselves: > > > https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher.md > > https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher-meta.md > > The following composer package for the interfaces themselves is also ready > to > use, on the 0.7 tag: > > https://packagist.org/packages/psr/event-dispatcher > > And a corresponding util package, at the 0.7.1 tag (sorry): > > https://packagist.org/packages/fig/event-dispatcher-util > > (We'll add a few more utilities to the util package before it actually > ships, > mostly provider tooling.) > > And a fully complete implementation to try is available here (0.7.1 tag): > > https://packagist.org/packages/crell/tukio > > We're collectively pretty happy with where we are at this point, and > encourage > all interested parties to try out the code above. We're planning another > meeting for next week and if no other issues are raised by then plan to > call a > Readiness Vote at that time. > > --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/03bd4868-e71d-4bb7-a6be-d44505414590%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/03bd4868-e71d-4bb7-a6be-d44505414590%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Matthew Weier O'Phinney [email protected] https://mwop.net/ he/him -- 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/CAJp_myWau-4k5s%3Dr5hRVpRZ%2BU1iTtAFxPJXOy8Zcoi16S3i0Hw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
