Ok, removed after and replaced all the boilerplate we added with AfterEvent<Event>.
Side note: i kept two passes with Invocation for fireEvent impl cause I think it can be useful but today it is not so we can revert too if you think it should Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-03-22 10:20 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>: > Thought the same but when you hack in arquilluan stack you realize it us > inefficient to understand the code. Your last commit proove it too: > > Firer(afterxxx) > Fire(afterxxxxxx) > > So we need a > > Fire(afterxxxxxxxxx) > > Makes code dumb to read and no more contextual so harder to follow. > > Can you change stop/start event you added with an ObserverEvent(event) > maybe? > > Le 22 mars 2014 05:46, "David Blevins" <david.blev...@gmail.com> a écrit : > >> I tend to agree on the I hope we don't need it thought. I'm thinking >> maybe we don't do either approach. >> >> For the large part, there's little difference between >> >> public void observe(final @Observes(after=A.class) SimpleEvent event) >> >> ..and >> >> public void observe(final @Observes AfterSimpleEvent event) >> >> The one difference is the LinkedList and Collections.sort calls (and the >> equals and/or string compares it involves) would not affect Observer >> performance. >> >> Seems like the cleaner API and the more performant. >> >> Agreed we still want to be careful how many events we add. >> >> >> -David >> >> On Mar 21, 2014, at 2:30 PM, Romain Manni-Bucau <rmannibu...@gmail.com> >> wrote: >> >> > yep both have advantages and drawbacks. One open question for me is >> > Class or String but not int cause first thing you'll do if not the >> > name (or class) is to look for all other adatpers...not efficient. >> > Class makes a forced dependency, String make it optional. ATM I think >> > Class is enough while we don't abuse of it in extensions like does >> > arquillian (which uses priority because it can't do anything else). >> > >> > I really hope we don't need it. >> > >> > Trying to summarize my thoughts: while internal events I think api is >> > nice and efficient but for the particular event we speak about we can >> > just fire a CDI event and benefit from @Priority very soon ;). Would >> > make everybody happy >> > Romain Manni-Bucau >> > Twitter: @rmannibucau >> > Blog: http://rmannibucau.wordpress.com/ >> > LinkedIn: http://fr.linkedin.com/in/rmannibucau >> > Github: https://github.com/rmannibucau >> > >> > >> > >> > 2014-03-21 21:09 GMT+01:00 David Blevins <david.blev...@gmail.com>: >> >> There are some downsides to reference based approaches as well. >> >> >> >> A.class: public void observe(final @Observes SimpleEvent event) >> >> Z.class: public void observe(final @Observes(after=A.class) >> >> SimpleEvent event) >> >> >> >> If you later want to add B.class or C.class in the middle between A and >> >> Z, you can't. >> >> >> >> As well you can't really express things like "low priority" and "high >> >> priority" >> >> >> >> EventLogger.class: public void observe(final @Observes(priority=1) >> >> Object event) >> >> >> >> >> >> On Mar 21, 2014, at 12:08 PM, Romain Manni-Bucau >> >> <rmannibu...@gmail.com> wrote: >> >> >> >>> -1 to index, it is what is in deltaspike, spec etc and it doesn't work >> >>> by design (see the spec already defined constants). For such an >> >>> internal thing we know where we want to bind our event so I still >> >>> think referencing the event is better. >> >>> >> >>> Always better to say where you want to be than saying "i want to be >> >>> here...almost" which is the index case. >> >>> Romain Manni-Bucau >> >>> Twitter: @rmannibucau >> >>> Blog: http://rmannibucau.wordpress.com/ >> >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >> >>> Github: https://github.com/rmannibucau >> >>> >> >>> >> >>> >> >>> 2014-03-21 20:02 GMT+01:00 David Blevins <david.blev...@gmail.com>: >> >>>> For Observers maybe we can find another way to achieve OPENEJB-2082 >> >>>> without binding one observer directly to another: >> >>>> >> >>>> public void observe(final @Observes(after = SimpleObserver.class) >> >>>> SimpleEvent event) >> >>>> >> >>>> I can see that creating just as much of a mess as having too many >> >>>> events. Having to sort each event is not exactly optimal for speed >> >>>> either. >> >>>> >> >>>> If we were to take a sorting based approach, maybe we can take a page >> >>>> from the interceptor ordering of Java EE 7, based on unix start orders: >> >>>> >> >>>> @Priority(5) >> >>>> public void observe(final @Observes SimpleEvent event) >> >>>> >> >>>> Default priority for all observers would be say, 5, like it is for a >> >>>> thread. We would recommend 1-10 as the range and use a float rather >> >>>> than an >> >>>> int so it can be easy to break a tie without complex hacking. >> >>>> >> >>>> Also as an optimization, we don't actually call the sort method >> >>>> unless one of the Observers actually has a priority. >> >>>> >> >>>> Thoughts? >> >>>> >> >>>> >> >>>> -David >> >>>> >> >> >> >
