Hey, thanks for your feedback.
About the dropped `stopPropagation()` method: Let's say, the library/application uses a Task that is used for rendering a view - let's call it `ResolveViewTask`. If any listener calls e.g. `ResolveViewTask->render()` this could/should set the `stopPropagation()` flag internally in the `ResolveViewTask` implicitly - so the task knows if it is taken care of already. A property or even the `stopPropagation()` method is actually not needed at all. There are lots of more examples like that - we checked in Symfony, Drupal and TYPO3... But if you have strong arguments FOR adding the additional method to the interface, let me know. All the best, Benni. > On 16. Sep 2018, at 21:43, [email protected] wrote: > > +1 for "renaming TaskInterface to TaskEventInterface and MessageInterface > to MessageEventInterface" > > Also, why: > > "We're going to remove stopPropagation() from the stoppable interface. It > will just have the isPropagationStopped() method for the Processor to use; > task implementers should define their own semantically-meaningful-in-their- > context method for indicating that propagation should be stopped. (Which if > they want to call it stopPropagation(), hey, that's their business.) " > > -- Is there a use case where "stopPropagation" does not make sense? If so, > can you please share? > > On Saturday, September 15, 2018 at 2:34:47 AM UTC+5, Larry Garfield wrote: > This is a special double-header edition, as we had a partial meeting last > week > with just 3 of us (damned scheduling conflicts!) and then a full meeting this > week. Highlights include: > > * We've added some more guidance to the metadoc on when to use Messages/ > Notifiers and when to use Tasks/Processors. > * Based on the survey results, we are going to split the interfaces into 3 > packages (the common bits, tasks, and messages). We're sticking with a > single > spec/Working Group, however, and probably a single namespace. > * We're still chewing on naming things. (It's hard, OK?) Tentatively we're > considering renaming TaskInterface to TaskEventInterface and MessageInterface > to MessageEventInterface, so that the "event" term is still in both. That > makes it a shorter conceptual jump for existing implementations and their > users. Still not finalized; we're going to sleep on it a bit and discuss > again next week. > * We're going to remove stopPropagation() from the stoppable interface. It > will just have the isPropagationStopped() method for the Processor to use; > task implementers should define their own semantically-meaningful-in-their- > context method for indicating that propagation should be stopped. (Which if > they want to call it stopPropagation(), hey, that's their business.) > * The recommendation to use *Task and *Message suffixes on event classes will > be removed, because Rich Hickey says so. > * We're tightening up the error handling so that Processors must allow > exceptions to bubble up, even if they catch-and-rethrow in order to do > additional error handling. That way it's consistent across implementations > and callers don't need to wonder whether they'll get an exception back or > not. > * Time permitting we're going to try building bridge implementations to make > sure that Zend and Symfony's current event systems can peacefully coexist > with > PSR-14 in a naturally-upgrading way. If someone wants to try bridging to > another existing implementation, now is a great time to do it! > > At present we are hoping to call a Readiness Vote within the next month or > two, although of course no promises are made here. > > --Larry Garfield, PSR-14 Editor > > -- > 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/892dca36-0a2f-49e9-a26d-f6bfa1c11792%40googlegroups.com > > <https://groups.google.com/d/msgid/php-fig/892dca36-0a2f-49e9-a26d-f6bfa1c11792%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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/DE9E333C-693F-4EDE-A669-F598038BAA1D%40gmail.com. For more options, visit https://groups.google.com/d/optout.
