Hey Alex, Thank you for your input. About PR 1152 I'm to be perfectly honest about it indifferent about it. Both phrases work for me and I'll leave that up to the rest of the WG which one works best.
About PR 1153 totally agree, in retrospect we should have never included it. The whole dealing with promises shouldn't have been done within the event dispatcher because if you want to combine events with chaining it you're looking at something like https://github.com/rdohms/chainlink or https://github.com/thephpleague/pipeline infused with promises. With regards to the MUST vs SHOULD, MUST is correct here because B is inheriting from A and inherits the same base class. Cheers, Cees-Jan On Sun, Feb 24, 2019 at 12:46 AM Alexandru Pătrănescu <[email protected]> wrote: > Hi working group, > > I spent some time reviewing the specs. > > I don't see any major issues but I have few items to discuss/improve: > > 1. Listeners. Phrase: *A Listener MAY delegate actions to other code. > That includes a Listener being a thin wrapper around retrieving an object > from a service container that contains the actual business logic to run, or > other similar forms of indirection. In that case, the callable containing > the actual business logic SHOULD conform to the same rules as if it were > called directly as a Listener.* > I can see an example that look this like: > $thinWrapperListener = function(BusinessEvent $event) use ($container, > $parameter2) { > $businessService = $container->get(BusinessService::class); > $businessService->process($event, $parameter2); > }; > I can't see why BusinessService:: process() should have a single parameter > and a void return. Or maybe this is not the intended meaning of the text *the > callable containing the actual business logic SHOULD conform to the same > rules.* > If meaning was different let's find a different phrasing. > > Also, the mention about a Listener that could be a thin wrapper looks fine > but the *wrapper around* part of the phrase I think it can be improved. I > suggest this rephrasing https://github.com/php-fig/fig-standards/pull/1152 > > 2. Dispatcher. Phrase: *As an exception to the previous point, if the > Event is a Promise object then the Dispatcher MAY return that Promise > before all Listeners have executed. However, the Promise MUST NOT be > treated as fulfilled until all Listeners have executed.* > If the Event is a Promise, Listeners would probably attach logic to be run > when the Promise will be resolved. But this would be exactly like the > normal flow. > The only case where the Dispatcher could return the promise before > executing all Listeners is if the Dispatcher would attach the Listeners > execution logic to be run when the Promise would be resolved. But the only > reason for this would be if the Listeners would be called with the event > resolved Value, contradicting the main phrase of the Dispatcher section: > *invoking > each Listener with that Event*. > Also *the Promise MUST NOT be treated as fulfilled until all Listeners > have executed* would be hard to implement with current libraries. If I'm > not wrong a promise would fulfill in regards to the initial async > fulfillment logic and, if one wants to have this behavior (adding more > rules to fulfillment), it would create a new Promise object based on the > previous one and the Listener execution calls. > With this in mind, I suggest we remove the line > https://github.com/php-fig/fig-standards/pull/1153 > > 3. Listener Provider. Phrase: *A Listener Provider MUST treat listener() > as an applicable listener for $b, as it is type compatible, unless some > other criteria prevents it from doing so.* > I think that MUST can be change to SHOULD, similar with how it was used in > a previous phrase: *Listener Providers SHOULD use the class name of an > Event to differentiate one event from another.* > As english is not my first language, I might miss on the interpretation of > words. > > > Regards, > Alex > > > On Thu, Feb 21, 2019 at 10:33 PM Larry Garfield <[email protected]> > wrote: > >> On Wed, Jan 30, 2019, at 12:31 PM, Cees-Jan Kiewiet wrote: >> > Yes 27th of February 2019 is the correct deadline. >> > >> > On Wed, Jan 30, 2019 at 7:17 PM Girgias <[email protected]> >> wrote: >> > > The review period deadline needs to be changed. The 27th of Jan 2019 >> was two days ago. >> > > Did you mean 27th of February 2019? >> > > >> > > Best regards >> > > >> > > George P. Banyard >> > > >> > > >> > > On Wed, 30 Jan 2019 at 19:05, Cees-Jan Kiewiet <[email protected]> >> wrote: >> > >> As of today, with a unanimous vote from the working group, we >> formally begin the REVIEW phase of the proposed PSR-14 (Event Dispatcher) >> specification. The proposed specification is in the fig-standards >> repository at the following locations: >> > >> >> > >> - Specification: >> https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher.md >> > >> - Metadocument: >> https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher-meta.md >> > >> >> > >> During the Review phase, acceptable changes to the specification >> include wording, typographical fixes, and clarifications. If you feel major >> changes are necessary or have, please bring your arguments/questions to the >> list under this thread. If any major changes are considered, we will return >> to the Draft phase. >> > >> >> > >> The Review period will end no sooner than 27 Jan 2019 at 11:59pm. At >> that time, if the working group can demonstrate two viable trial >> implementations, and no need for major changes, I will call for an >> Acceptance Vote. >> > >> >> > >> Cees-Jan Kiewiet, your friendly neighbourhood PSR-14 Sponsor >> >> Core Committee members: How shall the WG interpret your silence? :-) As >> approval or indifference? >> >> If approval, please let us know that you're approving so we know not to >> worry when it comes time to call a vote. :-) >> >> Beuller? >> >> --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/ac14ce13-e39b-4227-b9d7-68c7ef6bd834%40www.fastmail.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > 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/CAAwdEzDSFyjmppBkHk4U592tPL0A%3DGorCUswZk2pDQkP2RksGQ%40mail.gmail.com > <https://groups.google.com/d/msgid/php-fig/CAAwdEzDSFyjmppBkHk4U592tPL0A%3DGorCUswZk2pDQkP2RksGQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAPY1sU98TAxjWC0zrY5Lo4Dhdie%3DxY%3DvRbPtkDq2oDbHZ%2BQX7g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
