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
