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.
For more options, visit https://groups.google.com/d/optout.
