Larry, when will you be updating the repo to reflect the latest changes? On Friday, September 21, 2018 at 1:53:35 AM UTC+5, Larry Garfield wrote: > > 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
-- 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/37686764-1cb3-4604-8f95-345a2cd5ab96%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
