[PSR-14] Meeting Summary - 2018-09-13

[Larry Garfield]

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

[desig...@gmail.com]

+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?

[Benjamin Mack]

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.

-- 
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.

[desig...@gmail.com]

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.

[Larry Garfield]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/cd2d20ef-c052-4019-8768-4073a12c87b0%40googlegroups.com.

[Daniel Plainview]

> Task - A Task is a specific case of an Event that is bidirectional. 

I think this definition is not correct: Task (whatever it is) is not specific case of Event, because Event is never bidirectional. 

> Message - A Message is a specific case of an Event 

Event is special case of a message (likewise command), not vice versa.

I think these definitions would confuse people very much.

P.S. 

> renaming TaskInterface to TaskEventInterface and MessageInterface 

-Interface suffix buuuurrrns.

[Larry Garfield]

On Thursday, September 20, 2018 1:19:20 PM CDT Daniel Plainview wrote:
> > Task - A Task is a specific case of an Event that is bidirectional.
>
> I think this definition is not correct: Task (whatever it is) is not
> specific case of Event, because Event is never bidirectional.
>
> > Message - A Message is a specific case of an Event
>
> Event is special case of a message (likewise command), not vice versa.
>
> I think these definitions would confuse people very much.
>
> P.S.
>
> > renaming TaskInterface to TaskEventInterface and MessageInterface
>
> -Interface suffix buuuurrrns.

Daniel,

I appreciate your position that Event, in the academic sense, is a mono-
directional concept. It was your prompting that originally encouraged us to
split Messages and Tasks into separate workflows to begin with, which I
believe was very much the right decision.

However, the reality on the ground is that virtually every existing PHP
implementation in this problem space, as well as those in most other languages
we looked at, use the term "event". Symfony, Zend, Laravel, Doctrine, Guzzle,
Node.js, all of them use the term "event" to refer to a mutable object that
is, often, bidirectional. (And, by inheritance, the dozens of systems that
also leverage components from those libraries.) Removing the term "event"
from every single existing "event dispatcher" implementation would have the
net effect of making adoption dramatically harder and more cumbersome for
existing implementations to adopt PSR-14, and some we know simply wouldn't do
so. That's a non-starter.

FIG explicitly tries to balance "proper" technique, future-friendly design,
and the existing ecosystem when designing specifications. In cases like this
where there's a clear mismatch between those goals it means we need to
compromise somewhere.

In this case, using two terms that have relatively low collision with existing
implementations (and when they do, "Message" already means what PSR-14 defines
it to mean) as special cases of the universally-recognized term "Event" for
two different behavioral patterns is the best compromise that we've been able
to devise. The term "event" is still present, but in day to day practice
would actually be seen very little by most developers. That's as far from
existing practice as we feel comfortable to go, and even that is iffy.

--Larry Garfield
PSR-14 Editor

[desig...@gmail.com]

Larry, when will you be updating the repo to reflect the latest changes?

[Larry Garfield]

On Thursday, September 20, 2018 6:04:32 PM CDT desig...@gmail.com wrote:
> Larry, when will you be updating the repo to reflect the latest changes?

The 0.5.0 tag of psr/event-dispatcher is fully up to date with the spec and
you can build against that today.

As noted previously, expect it to get split into 3 packages soon and the Task
and Message interfaces MAY change names/namespaces. Those should be pretty
minor changes, though. The architecture itself is reasonably well set.

--Larry Garfield