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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/1714422.TBpfYqdE6Y%40vulcan. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: This is a digitally signed message part.
