On Jul 22, 2010, at 1:34 PM, Michael Wooten wrote: > I've been talking it over with James and we've considered the option > of swapping the inheritance chain so that there is an > EventListenerSource class that extends EventListenerSupport but > includes the "source" property and documentation on how to write > subclasses as described in the AbstractEventSupport javadocs. > > This approach would allow subclasses to make use of fire() when > writing their own custom "fire" event methods. > > Opinions on this solution? >
I think I can live with this compromise. -Matt > 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
