commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Wooten <>
Subject Re: [VOTE] Release Commons Lang 3.0 Beta.1
Date Thu, 22 Jul 2010 16:44:00 GMT

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.



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 <> wrote:
> On Jul 22, 2010, at 10:08 AM, James Carman wrote:
>> On Thu, Jul 22, 2010 at 11:02 AM, Matt Benson <> 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
>> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message