On Jul 26, 2010, at 12:13 PM, James Carman wrote: > 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.
I can't argue much, because my $work stuff indeed does have a listener interface that does not extend EventListener... -Matt > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
