[PSR-14] Meeting summary - 2018-04-26

50 views
Skip to first unread message

Larry Garfield

unread,
Apr 26, 2018, 4:51:01 PM4/26/18
to php...@googlegroups.com
The PSR-14 WG had its first meeting today.

Highlights:

* There are many types of message-passing-thingies in the wild, from basic
pub/sub to signals/slots.
* Liz has an older presentation here that details them well: https://
www.slideshare.net/auroraeosrose/event-and-signal-driven-programming-14873505
* MWOP also has an older post on the subject: https://mwop.net/blog/251-aspects-filters-and-signals-oh-my.html
* Most PHP libraries in the wild today use the "event dispatcher" style, which
is basically subject/observer with a mediator object. That's what the
ecosystem has settled on as the best model given the language we have.
* We identified a number of major use cases that a common interface will need
to address, as well as several that are nice-to-have.
* We also identified a whole bunch of decision points that will need to be
made, and various existing systems use almost every combination of them.
Standardizing on some of these will almost certainly annoy someone, but will
have to be done in order for a standard to exist, by definition. C'est la vie.
Some of these include:
* Are events identified by an identifier string or by the class of an event
object?
* Should events carry a stateful payload, and if so, should events be
treated pass-by-value immutable-ish or not? Do they return to the caller?
* Should it be possible to "group" events so a single listener can listen to
a set of events at once?
* How much control should the spec provide over the order in which listeners
fire vs. leaving that to implementers to figure out?
* Should listeners support middleware-style enhancement?
* Should events be interruptable? (That is, can a listener say "Stop
Propagation"?)
* These are all still "to be determined" at this point.


Key decisions:
* As expected, we're looking at an event-dispatcher style, NOT direct
observer, NOT signal/slots.
* We will be targeting PHP 7.1 as a minimum version. That is clearly the
minimum version that the broader community has chosen so it is a fairly safe
target.
* We concluded it would also be wise to review the APIs used in various other
languages, if only for inspiration (including for what not to do). We will be
doing informal reviews of Python, Ruby, Node.js, Java, and C#'s event handling
before our next meeting to see what can be learned from them.
signature.asc
Reply all
Reply to author
Forward
0 new messages