Any Task can opt-in to being stoppable. However, a task should stop when some domain-relevant action has been taken. Consider the Symfony View event, which is sort of the canonical example for this use case.
The event/task is "done" when some listener has called setResponse(). That means the program can continue. However, what happens is someone calls stopPropagation() world setting a response object? I think currently you get a null error somewhere, because you're violating the domain model expectations.
Consider also a task that wants to only be handled by 4 listeners, or 4 listeners that take some action. Having a blanket flag method world be an end run around that requirement.
A spec should not require an implementer you violate their domain model expectations.
Instead, it's up to the implementer to decide what constitutes "done", and inform the Processor.
Of course, an implementer is free to offer a blanket flag method of they want. That's up to them. We expect Symfony will keep its stopPropagation() method for BC reasons, which is fine.
If you're writing a listener against a task, you know what its API is, if it is stoppable, and what its stop condition is. So there's no confusion, just no requirement that a task violate its domain model constraints.
To be clear, since it seems you may be confused, the Stoppable interface is still there and any task can implement it to become stoppable. It's just the mechanism by which a listener indicates to the task that it's done that's left up to the implementer to decide.
--Larry Garfield
On Sep 17, 2018 1:43 PM, designc...@gmail.com wrote:
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, desig...@gmail.com 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 php-fig+u...@googlegroups.com .
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/892dca36- .0a2f-49e9-a26d-f6bfa1c11792% 40googlegroups.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 php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
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.
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 php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/48b5709f-9823-4b4d-b42d-d2a00d578479%40email.android.com.
For more options, visit https://groups.google.com/d/optout.
