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
