For GenericConcern that's the case, it help remomebering, but for GenericSideEffect is not at allas the methods are implemented. I'm still for removing them but if you guys wanna keep them then let's make the InvocationHandler#invoke method final and the 2 params invoke abstract in GenericSideEffect. This way if you want to override the method with 3 params then you will extend the SideEffectOf because it makes no sense to extend GenericSideEffect and you will also not forget about implementing the 2 params method.
Alin On Sat, Jun 14, 2008 at 11:20 AM, Michael Hunger <[EMAIL PROTECTED]> wrote: > I think we should keep it. I removed it locally and it was much more pain to > do all the SideEffectOf<InvocationHandler> > implements InvocationHandler myself (first I forgot the implements > InvocationHandler). So I reverted the removal. > > For developers writing their own generic side effects/concerns these classes > would certainly help going. > > Michael > > Alin Dreghiciu schrieb: >> Still there is the question: Do we need or not >> GenericConcern/SideEffect and if yes what is the added value? >> >> Alin >> >> On Fri, Jun 13, 2008 at 8:23 PM, Rickard Öberg <[EMAIL PROTECTED]> wrote: >>> Niclas Hedhman wrote: >>>> On Thu, Jun 12, 2008 at 5:58 PM, Alin Dreghiciu <[EMAIL PROTECTED]> wrote: >>>>> Looking at GenericSideEffect I do not see the added value of having >>>>> this class beside the small benefit of the fact that by inheriting it >>>>> you get the extends of SideEffectOd and implements InvocationHandler. >>>>> Can it be that is there for a future use where we could add something >>>>> to it and so all the subclasses will inherit it? >>>> I think we should redo it so that there are protected methods; >>>> >>>> protected abstract void beforeInvoke( Method method, Object[] args); >>>> >>>> protected abstract void onSuccess( Object returnValue ); >>>> >>>> protected abstract void onException( Throwable exception ); >>>> >>>> >>>> or something like that and make the invoke() final, as suggested. >>> Like Alin said, this would only make sense for GenericConcern, not >>> GenericSideEffect. The problem with this kind of construct is that it >>> creates a small but unnecessary performance cost, since it will be >>> invoking a couple of no-op methods for no good reason. It's easy enough >>> to do the above manually. >>> >>> I'd say -1 on these for now. They are easy to add later if some really >>> good arguments come up. >>> >>> /Rickard >>> >>> _______________________________________________ >>> qi4j-dev mailing list >>> [email protected] >>> http://lists.ops4j.org/mailman/listinfo/qi4j-dev >>> >> >> >> > > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > -- Alin Dreghiciu http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development. http://malaysia.jayway.net - New Energy for Projects - Great People working on Great Projects at Great Places _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
