[PSR-14] Meeting Summary - 2018-07-12

[Larry Garfield]

The Working Group met again today to chew on alpha 1 further. It was rather
spirited (in a good way!), but here are the highlights:

* We're going to collapse the modifiable and stoppable dispatchers into a
single dispatcher. That way the opt-in process for stoppable is just adding
an interface to the event rather than also needing a different method/service
to dispatch to.
* We're fairly sold on the notify and modify workflows being separate
conceptual use cases, so those will remain distinct interfaces. In
particular, notify events must be serializable, must be immutable, and must be
async-safe. Modify events have none of those requirements and contradict them
in some cases.
* However, we then started tackling one of the hardest problems in computer
science (naming things); are they different enough that we should name the
methods the same so as to FORCE them to be implemented by separate objects?
The jury is still out.
* The naming and typing of the methods then becomes interesting. If the same,
several potential words are already in use, eg, `dispatch` by Symfony and
`trigger` by Zend. Whether it's good or bad to reuse one of those is an open
question.
* Related, with a PHP 7.1 dependency (not 7.2) using either dispatch or
trigger would be potentially problematic for Symfony/Zend if the method is
typed. A typed object parameter would conflict with the existing method in
those systems whereas an untyped parameter would allow the implementations to
support both PSR-14 and their legacy system simultaneously. The jury is still
out here, too.
* Related, do we still want to have the marker interface for Events? And if
so, do we want a separate marker interface for notify events vs mutable
events? The jury has no idea what it wants to do here. :-)

Questions for the audience then, *especially* those that are likely to be
implementing PSR-14 (anyone who is close with the Doctrine or Laravel folks
that can jump in here?):

* Are there method names for the dispatcher that would definitely make it
harder for you to adopt PSR-14?
* Would you freak out about having a marker interface (an empty interface that
must be implemented to serve as a flag) for events, or freak out at not having
one and allowing an arbitrary object?
* Do you have a strong feeling about notify and modify dispatchers being
implementable as the same service? (Viz, should we actively make it easy to
do, or actively make it hard to do?)

Cheers folks!

--Larry Garfield
PSR-14 Editor

[Larry Garfield]

[Daniel Plainview]

You probably should require to catch all kind of exceptions/errors for "true" event listeners.

The reason is simple: listener's execution time becomes undefined for caller and exceptions become meaningless.

For the same reasons we don't throw exceptions from destructors, by the way.

[Daniel Plainview]

> should require to catch all kind of exceptions/errors for "true" event listeners

Maybe I wasn't clear enough, just to be precise: I mean, implementation of EventDispatcher must not rethrow any exceptions/errors from event listeners, all executors of async event listeners must not stop work if event listener fails.

They should log error, but as I said, correct implementation must behave like event listeners are somewhere in separate process, 

In other words, event listener is not connected to the original call stack in general and the caller is not responsible for this.

[Larry Garfield]

On Thursday, July 26, 2018 1:36:25 PM CDT Daniel Plainview wrote:
> > should require to catch all kind of exceptions/errors for "true" event
>
> listeners
>
> Maybe I wasn't clear enough, just to be precise: I mean, implementation of
> EventDispatcher must not rethrow any exceptions/errors from event
> listeners, all executors of async event listeners must not stop work if
> event listener fails.
> They should log error, but as I said, correct implementation must behave
> like event listeners are somewhere in separate process,
>
> In other words, event listener is not connected to the original call stack
> in general and the caller is not responsible for this.

That's a good point, and another case where the notify and modify pipelines
behave differently. I can totally see where for a modify event you would want
an exception to bubble up, but you're right that for a notify event it should
not.

We haven't really talked about error handling much yet, but I've added it to
the agenda for our next meeting.

An interesting approach that the Node event handler we looked at took was to
catch exceptions and convert them to another event type, on which you can
register listeners to act as error handlers. I'm not sure if that works well
for the modify events. Probably not for notify events, but modify maybe.

Thoughts?

--Larry Garfield