> 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. On Saturday, September 15, 2018 at 12:34:47 AM UTC+3, Larry Garfield wrote: > > 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 > -- 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/7e3c9f7d-1f43-46fe-bf1c-3f1db98d4abd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
