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
