[PSR-14] Meeting Summary - 2018-10-23

[Larry Garfield]

We were joined today by Nicolas Grekas in a guest appearance from Symfony.
Nicolas had a number of concerns he wanted to bring up to the working group
directly. There's three key takeaways from today's call that are relevant:

1) Nicolas brought up the naming question (again). The "task" naming is one
of the hangups for a number of people, because every single existing
implementation in all of PHP and Javascript for what PSR-14 calls tasks calls
it "Events" today. While it's less common outside of PHP, PHP is obviously
the primary constituency and Javascript the most likely "second language" for
PHP devs. Renaming "task" to "Event" and then removing the parent marker
interface is on the table for consideration. (If you have feedback here that
hasn't been offered and considered yet, it is welcome.)

2) Removing the parent marker interface would necessitate splitting the
Provider into two, one for tasks/events and one for messages. We are going to
experiment and see how viable that is and if it would have any unpleasant (or
pleasant for that matter) side effects.

3) Nicolas also argued in favor of making the provider take an opaque string
rather than the event object itself to determine what listeners are relevant.
The main arguments in favor of doing so are a small performance boost in a
common case and easier support for dynamic event names (based on user
configuration, for instance.) The arguments against are that it's vastly less
flexible for anything but that one common case, and the performance difference
is not significant. We're going to mull this one over further, but if I can
editorialize a bit I think the arguments for changing this are not very
compelling.

That's it for now. Feedback on the above points is, as always, welcome here
on the list.

--Larry Garfield

[desig...@gmail.com]

Hi Larry,

Just curious to know what the progress on PSR-14 is? When can we expect to get a final vote, etc.?

Thanks!

[Larry Garfield]

Greetings.

I've been holding off on posting another meeting summary as it's been a bit
haphazard lately, and we've been circling essentially the same question for a
while. Offering a blow-by-blow of that didn't seem very useful or productive.

At this point, I'm not sure on a date for the Readiness Vote. The main open
question at the moment is whether we include marker interfaces -- and thus
type declare everything -- or not -- and thus the spec has basically no type
declarations anywhere. The question is whether the marker interfaces add more
robustness than they cause possible BC issues for some existing
implementations (particularly for the unidirectional case), a question on
which there are multiple competing opinions at present.

Regarding the points from last time (below), if we keep the marker interfaces
then we keep the parent marker, which is likely to be renamed
DispatchableInterface. The experimentation of forcing 2 separate Providers
for the unidirectional and mono-directional case showed it was... not a good
idea. We're also all agreed on type-as-identifier (as the spec is now), as it
offers way more flexibility and robustness than opaque strings do.

More information when there's more information to be had. :-)

--Larry Garfield