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