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 On Sunday, November 25, 2018 10:57:48 AM CST [email protected] wrote: > Hi Larry, > > Just curious to know what the progress on PSR-14 is? When can we expect to > get a final vote, etc.? > > Thanks! > > On Wednesday, October 24, 2018 at 12:35:10 AM UTC+5, Larry Garfield wrote: > > 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 -- 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/3293422.7ansvBbx8Q%40vulcan. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: This is a digitally signed message part.
