[PSR-14] Meeting Summary - 2019-01-09
87 views
Skip to first unread message
Larry Garfield
Jan 10, 2019, 12:13:58 AM1/10/19
to php...@googlegroups.com
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
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
desig...@gmail.com
Jan 10, 2019, 7:01:42 AM1/10/19
to PHP Framework Interoperability Group
Glad to see this is in working mode again. I would love to know if there are any other example implementations done for the latest spec? Thanks!
Matthew Weier O'Phinney
Jan 10, 2019, 9:48:04 AM1/10/19
to php...@googlegroups.com
On Thu, Jan 10, 2019 at 6:01 AM <desig...@gmail.com> 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.
--
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/03bd4868-e71d-4bb7-a6be-d44505414590%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
he/him
desig...@gmail.com
Jan 10, 2019, 9:24:32 PM1/10/19
to PHP Framework Interoperability Group
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?
Matthew Weier O'Phinney
Jan 11, 2019, 3:10:08 PM1/11/19
to php...@googlegroups.com
On Thu, Jan 10, 2019 at 8:24 PM <desig...@gmail.com> 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/8524a1dc-cca6-41f4-8199-956479c43032%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
desig...@gmail.com
Jan 30, 2019, 3:23:12 AM1/30/19
to PHP Framework Interoperability Group
Shouldn't the `object` typehint be backslashed like so:
Because using it as is yields the following error:
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 ...
desig...@gmail.com
Jan 30, 2019, 3:43:40 AM1/30/19
to PHP Framework Interoperability Group
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+
Reply all
Reply to author
Forward
0 new messages