On Jul 22, 2010, at 12:41 PM, Michael Wooten wrote: > Matt, > > Technically the AbstractEventSupport class itself doesn't add that > much value. It is meant more as a utility for someone providing their > own listeners and events. It is just one of those classes I've > rewritten on many projects that I work on. > > The benefit of extending AbstractEventSupport over using > EventListenerSupport is that you can add your own "fire" method that > may provide better meaning to the user, or offer additional > functionality. The class is designed to be a base class for classes > similar to PropertyChangeSupport. PropertyChangeSupport offers methods > for firing both PropertyChangeEvents and IndexedPropertyChangeEvents > objects through utility methods, with different behaviors for how the > the event object is constructed depending on which method is called. > The idea is that the user doesn't have to know how the event object is > constructed or how it is propagated to the listeners, just that it is. > By extending AbstractEventSupport and adding your own "fire" methods > you can create support classes with simpler interfaces and more > semantic meaning (documentation, potential error checking). >
My point was that one could just as easily add these methods to a subclass of EventListenerSupport. :) -Matt > Hope this helps. > > -Michael > > On Thu, Jul 22, 2010 at 12:56 PM, Matt Benson <gudnabr...@gmail.com> wrote: >> >> On Jul 22, 2010, at 11:44 AM, Michael Wooten wrote: >> >>> All, >>> >>> Since I started this mess with LANG-580 I figured I would chime in. >>> >>> I personally believe that there is a benefit for the EventSupport >>> interface, even if it can only register one type of listener. >> >> >> Silly me; I was talking as though EventSupport hadn't been proposed. Well, >> as I said, it's good as far as it goes, but doesn't outright address the >> case where an object might accept multiple eventlistener types. The obvious >> thing here is that a class can implement EventSupport<EventListener>. It >> then follows that such a class would dispatch to multiple >> AbstractEventSupport or EventListenerSupport objects. Do any ideas occur to >> anyone here? Could we provide a special-purpose EventListenerSupport >> subclass that explicitly assigns the type parameter as EventListener, then >> dispatches listeners accordingly and perhaps overloads fire() to take the >> actual listener type? I'm thinking I like this idea and may attempt to >> implement it. >>> >> >>> I also >>> believe that AbstractEventSupport could be very useful. It basically >>> provides an abstract base class for classes that are intended to work >>> much like PropertyChangeSupport works, with utility methods for >>> posting events and all of the listener management handled for you. The >>> idea is that you wouldn't have to create the event objects yourself, >>> you would just call utility methods that would create the event and >>> fire it. I am very impressed with James's implementation of >>> EventListenerSupport, and believe it is a much better solution than >>> the ReflectiveEventSupport class that I contributed. >> >> Still, what could you do with AbstractEventSupport that you couldn't do with >> EventListenerSupport? Unless there's some reason to avoid proxy generation >> in some environments... I have no real argument against, just curious. >> >> -Matt >> >>> >>> I have created another patch in LANG-580 that showcases what I believe >>> is a best-of-both-worlds solution. I removed the >>> ReflectiveEventSupport class and changed James' EventListenerSupport >>> class to extend AbstractEventSupport. Please look over this solution >>> and see if it meets everyone's needs. >>> >>> Thanks. >>> >>> -Michael >>> >>> P.S. I also contributed a patch with the package.html file for the >>> event package. This will need to be updated however based on whatever >>> is decided. >>> >>> On Thu, Jul 22, 2010 at 11:20 AM, Matt Benson <gudnabr...@gmail.com> wrote: >>>> >>>> On Jul 22, 2010, at 10:08 AM, James Carman wrote: >>>> >>>>> On Thu, Jul 22, 2010 at 11:02 AM, Matt Benson <gudnabr...@gmail.com> >>>>> wrote: >>>>>> I like the compiler-checked aspect of your code, James, considering it >>>>>> scratches an itch reminiscent of my current work in [proxy]. I'm happy >>>>>> for your code to survive this POE. >>>>>> >>>>> >>>>> I think it reads very well, too. The fire() method used to be named >>>>> getProxy(), but I like fire() much better because it makes it read >>>>> like a sentence. I do believe I'm going to make the >>>>> EventUtils.addEventListener() method private. It really doesn't add >>>>> much value to outside folks. Its primary purpose is an implementation >>>>> method for the other bindEventsToMethod() method. WDYT? >>>>> >>>> >>>> Well, I can see *some* value in having it, due to the fact that there are >>>> no well-known interfaces for *listenable* items. We could provide a >>>> generic interface as a wannabe defacto standard, but it would fall down as >>>> soon as somebody wanted to support multiple listener types on a single >>>> object. I've been doing a lot of event-listening code at $work recently >>>> (over the past year) and this has been a big PITA. I can't see a way >>>> generic enough for [lang] to handle this problem, so I might vote for >>>> #addEventListener() to remain. However, you might add an analogous >>>> remove() in that case. Finally, a bit of code to take away from the other >>>> event-stuff is the null-checking of the added/removed listeners. ;) >>>> >>>> -Matt >>>> >>>>> --------------------------------------------------------------------- >>>>> 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
