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? 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
