I wouldn't do it. Folks don't necessarily extend EventListener, although they should. I think it's adding restriction without adding too much value. If EventListener had some methods on it that we depended on then that would be a different story.
On Mon, Jul 26, 2010 at 12:16 PM, Michael Wooten <mwooten....@gmail.com> wrote: > +1 to restricting the type. > > On Mon, Jul 26, 2010 at 12:05 PM, Matt Benson <gudnabr...@gmail.com> wrote: >> 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 >> >> > > --------------------------------------------------------------------- > 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
