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
>>>>
>>
