Sorry, I didn't read whole thread, but I don't think it's fair to compare @throws and @triggers/@event/whatever.
@throws is a public contract supported by language. It's not about documentation in the first place. IDE (PhpStorm) reports me if I missed catch block for non-RuntimeException. My code may have a bug if I miss some checked exception. @triggers is just some framework/implementation detail. For example, I don't like Symfony's EventDispatcher for its eventName, eventClass separation, it encourages to have generic FooEvent with several "event names" (aka event identifiers): "foo_was_boomed", "foo_was_doomed". I prefer to have fine-grained events (each event has its own class): FooWasBoomed, FooWasDoomed. Further, I like to make strict difference between events and hooks. Events are "fire-and-forget", event listeners can be triggered synchronously, asynchronously (shutdown function or queues) and I don't care about them. Hooks are special thing for involving 3rd parties into my flow, they are synchronous. Symfony, on other hand, mixes these 2 concepts in 1. Thus, I see here too many personal preferences, so it makes me wonder what makes Symfony approach so special, so it should have special annotation on PSR level? On Tuesday, December 13, 2016 at 6:49:27 PM UTC+3, Grzegorz Korba wrote: > > So what about using @triggers (like @throws) instead of @event? I see > @Event "annotation" is used for example in > \Symfony\Component\HttpKernel\KernelEvents for describing class related to > event's name and I think it's better usage for it. > > I'm sorry for digging it out since it's old thread, but I came here from > google results and don't know if it's closed :-) > > > W dniu czwartek, 18 października 2012 20:09:48 UTC+2 użytkownik Niels > Braczek napisał: >> >> Am 18.10.2012 16:49, schrieb Drak: >> >> > In the end, the same is true - listeners are notified of something >> > happening which does not require they specifically do something. It's >> very >> > much passive. Notification is passive. Triggering is not. >> >> It's not about listeners, it is about events. >> >> The listeners are not known at development / documentation time, since >> they are added at runtime. Thus, the *notification* of any specific >> listener is not documentable/relevant. What needs documentation is the >> event (or signal) that is *triggered*, so a developer / an IDE can see, >> which events a listener can react on. >> >> Regards, >> Niels >> >> -- >> | http://barcamp-wk.de · 2. Barcamp Westküste Frühjahr 2013 | >> | http://www.bsds.de · BSDS Braczek Software- und DatenSysteme | >> | Webdesign · Webhosting · e-Commerce · Joomla! Content Management | >> ------------------------------------------------------------------ >> > -- 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/741159e5-b5a4-41a2-b6be-951c631fd638%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
