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" <[email protected]> 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 <[email protected]> > 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 <[email protected]>: > >> 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 <[email protected]> > 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 <[email protected]>: > >>>> 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 > >>>> > >> > >
