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