+1 agreed. I think that there is a usefulness in both cases Matt mentions. May I also suggest that the interface be named EventSource instead of EventSupport, so as to avoid confusion with the EventListenerSupport class and better identify the class as being a source of events.
-Michael On Mon, Jul 26, 2010 at 12:18 PM, Matt Benson <gudnabr...@gmail.com> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
