+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
