I think adding the EventSupport interface still has value; as mentioned before, some type that needs to support > 1 listener type can still implement EventSupport<EventListener> and this is more valuable than having no interface whatsoever with which to manipulate the object's listeners.
The primary difference I see between the historical declaration of such a multi-event-type-generating class vs. the expected structure of one implementing EventSupport<EventListener> is that in the old class you would have two addListener methods, e.g. addListener(PropertyChangeListener) and addListener(VetoableChangeListener). In the event that a listener object implements both interfaces, it would (depending on class structure, but presumably) need to be added via both methods in order for it to receive both event types. If a single interface method like EventSupport<EventListener>.addListener(EventListener) is used to add that listener, events of any supported type should presumably be triggered on it. Because the must-be-registered-by-both-methods requirements of "the old way" are not in any way enforced, however, I think the events-will-be-fired-for-any-supported-EventListener-interface behavior of "the new way" are reasonable, particularly if [lang] supplies a class to make it easy to manage that type thing as I plan to. Thoughts? -Matt On Jul 22, 2010, at 1:38 PM, James Carman wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
