Benni, I get that there are a few use cases that may account for say 20 - 30% (and that's a generous number) of various uses cases where this may be true. However, for the predominant use case for a task event, such as in an event manager/dispatcher library, stop propagation will be an integral feature. That for me is a very solid reason to include stopPropagation method; 1) for the common/popular usage in most use cases; 2) to enforce a setter for propagation.
Even in the use case you mentioned you say "this could/should set the `stopPropagation()` flag internally" -- in that case, could they not simply call the "stopPropagation" method? Because essentially it's doing that along with performing another task, i.e. "rendering view", in your example. The only specific use case where I can imagine a setter for propagation property not being used at all is if the propagation property were immutable. That's my argument for including stopPropagation method; it is kind of enforcing a good practice here, and should not be left out I believe. On Monday, September 17, 2018 at 12:59:05 AM UTC+5, Benni Mack wrote: > > 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] <javascript:> 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] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > 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. > > > -- 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/cd2d20ef-c052-4019-8768-4073a12c87b0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
