commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [VOTE] Release Commons Lang 3.0 Beta.1
Date Thu, 22 Jul 2010 17:43:56 GMT

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 <gudnabrsam@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 <gudnabrsam@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 <gudnabrsam@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-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> 
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message