To try and get this whole subject put to bed, is anyone opposed to restricting the bounds of EventListenerSupport's <L> variable to <L extends EventListener>? It's not strictly necessary, but without the restriction, the listener semantics of the ELS class itself are completely superficial, in which case why wouldn't we just rename the class CompositeManager, put it in a different package, and make its method names more generic?
-Matt On Jul 22, 2010, at 1:38 PM, James Carman wrote: > Yes, that's what we're (so far Matt and me) suggesting. There's no > need for an abstract superclass here. > > On Thu, Jul 22, 2010 at 2:34 PM, Paul Benedict <pbened...@apache.org> wrote: >> Sorry about "no-op" implementation.. I meant default implementation. I >> believe a worthy goal would be to use EventListenerSupport out of the box, >> if possible, and allow subclassing for further customization. >> >> On Thu, Jul 22, 2010 at 1:29 PM, James Carman >> <ja...@carmanconsulting.com>wrote: >> >>> I think we're leaning toward just having EventListenerSupport. >>> >>> On Thu, Jul 22, 2010 at 2:27 PM, Paul Benedict <pbened...@apache.org> >>> wrote: >>>> I have a philosophical problem with EventListenerSupport extending >>>> AbstractEventSupport. I look at the class names, and I ask what does the >>>> concrete class do that AbstractEventSupport doesn't? I say either provide >>>> one abstract class, or one concrete class, but not both. >>>> >>>> On Thu, Jul 22, 2010 at 1:23 PM, Matt Benson <gudnabr...@gmail.com> >>> wrote: >>>> >>>>> Paul: As of now there are two options. The first is to remove >>>>> AbstractEventSupport in favor of EventListenerSupport. The second is >>> for >>>>> EventListenerSupport to extend AbstractEventSupport. >>>>> >>>>> -Matt >>>>> >>>>> On Jul 22, 2010, at 1:21 PM, Paul Benedict wrote: >>>>> >>>>>> I looked at both in SVN and see convergence and not too much >>> difference. >>>>> Can >>>>>> you guys agree to removing one? Which one? I know the classes are not >>>>>> identical, but they are similar enough to go "hmmm". >>>>>> >>>>>> On Thu, Jul 22, 2010 at 1:17 PM, Matt Benson <gudnabr...@gmail.com> >>>>> wrote: >>>>>> >>>>>>> >>>>>>> On Jul 22, 2010, at 1:11 PM, Paul Benedict wrote: >>>>>>> >>>>>>>> Does EventListenerSupport provide anything useful besides a no-op >>>>>>>> implementation? >>>>>>>> >>>>>>> >>>>>>> EventListenerSupport does. AbstractEventSupport IMO provides little >>>>> over >>>>>>> ELS: an Object event source, which in my experience is not >>> necessarily >>>>> the >>>>>>> greatest paradigm to emulate anyway. >>>>>>> >>>>>>> -Matt >>>>>>> >>>>>>>> On Thu, Jul 22, 2010 at 12:49 PM, James Carman >>>>>>>> <ja...@carmanconsulting.com>wrote: >>>>>>>> >>>>>>>>> On Thu, Jul 22, 2010 at 1:43 PM, Matt Benson <gudnabr...@gmail.com >>>> >>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> My point was that one could just as easily add these methods to a >>>>>>>>> subclass of EventListenerSupport. :) >>>>>>>>>> >>>>>>>>> >>>>>>>>> +1, agree with Matt here. Why not just extend EventListenerSupport >>>>>>>>> and add your custom fire* methods there? But, if you don't want to >>>>>>>>> add custom fire methods (and you really don't need to with the >>> proxied >>>>>>>>> fire() method), then you can just use the EventListenerSupport >>> class >>>>>>>>> directly. >>>>>>>>> >>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
