Awesome!
BTW hope we'll not bother code with events everywhere even if free,
was very disppointed by arquillian when browsing event of event of
event etc...Makes the code impossible to follow. So I still think
events should be meaningful and extension oriented.
In all cases thanks for this hack w
On Mar 22, 2014, at 2:56 PM, David Blevins wrote:
>
> On Mar 22, 2014, at 4:15 AM, Romain Manni-Bucau wrote:
>
>> removed after and replaced all the boilerplate we added with
>> AfterEvent.
>
> Love it. Looks very elegant. Added a BeforeEvent to round it out.
>
> Have some ideas to optim
On Mar 22, 2014, at 4:15 AM, Romain Manni-Bucau wrote:
> removed after and replaced all the boilerplate we added with
> AfterEvent.
Love it. Looks very elegant. Added a BeforeEvent to round it out.
Have some ideas to optimize. Ideally before/after could be zero cost unless
there are actua
Ok,
removed after and replaced all the boilerplate we added with AfterEvent.
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://rmannib
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(afterxx)
So we need a
Fire(afterx)
Makes code dumb to read and no more contextual so harder to follow.
Can you change st
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 AfterSimpleEve
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 do
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, yo
-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 w
