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