Sorry, upon digging deeper, I realized it was because I had an earlier version of PHP (v7.1) running in cli. It works fine in PHP 7.2+
On Wednesday, January 30, 2019 at 1:23:12 PM UTC+5, [email protected] wrote: > > Shouldn't the `object` typehint be backslashed like so: > > public function getListenersForEvent(\object $event) : iterable; > > Or earlier in the code: > > use \object; > > Because using it as is yields the following error: > > Fatal error: Declaration of > CommandListenerProvider::getListenersForEvent(object $event): iterable must > be compatible with > Psr\EventDispatcher\ListenerProviderInterface::getListenersForEvent(Psr\EventDispatcher\object > > $event): iterable ... > > > On Saturday, January 12, 2019 at 1:10:08 AM UTC+5, Matthew Weier O'Phinney > wrote: >> >> >> >> On Thu, Jan 10, 2019 at 8:24 PM <[email protected]> wrote: >> >>> Thanks Matthew! >>> >>> I'm a little iffy about type hinting $events as 'object', a marker >>> EventInterface seems much better here, no? I know you guys probably debated >>> a lot about this and got to this point, and I understand that the former is >>> better for backward compatibility and supporting existing implementations, >>> but `EventInterface` has more of a semantic value, no? >>> >> >> We did indeed go back and forth on this one a lot. >> >> When surveying the various event systems, what we found was a solid mix >> of those that have specific event types, and those that allow passing >> arbitrary objects. The latter are interesting, because they allow you to >> pass your existing business objects as events, which allows them to remain >> agnostic of the fact that they may be used in that fashion. If we forced >> implementation of an interface, this would break such use cases. >> >> In then end, we did not find enough justification for the marker >> interface to exist, while there were plenty of good reasons to omit it. >> Additionally, if PHP eventually fully supports its stated covariant >> parameters/contravariant return types for all methods, this would allow >> developers to provide more specific types to the arguments and/or return >> values safely. >> >> On Thursday, January 10, 2019 at 7:48:04 PM UTC+5, Matthew Weier >> O'Phinney wrote: >>> >>> >>> >>> 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/8524a1dc-cca6-41f4-8199-956479c43032%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/php-fig/8524a1dc-cca6-41f4-8199-956479c43032%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/0e780962-8751-4a4f-b7d1-09dea01cb385%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
