commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject [lang] EventSupport interface WAS Re: [VOTE] Release Commons Lang 3.0 Beta.1
Date Mon, 26 Jul 2010 16:18:14 GMT
I think adding the EventSupport interface still has value; as mentioned before, some type that
needs to support > 1 listener type can still implement EventSupport<EventListener>
and this is more valuable than having no interface whatsoever with which to manipulate the
object's listeners.

The primary difference I see between the historical declaration of such a multi-event-type-generating
class vs. the expected structure of one implementing EventSupport<EventListener> is
that in the old class you would have two addListener methods, e.g. addListener(PropertyChangeListener)
and addListener(VetoableChangeListener).  In the event that a listener object implements both
interfaces, it would (depending on class structure, but presumably) need to be added via both
methods in order for it to receive both event types.  If a single interface method like EventSupport<EventListener>.addListener(EventListener)
is used to add that listener, events of any supported type should presumably be triggered
on it.  Because the must-be-registered-by-both-methods requirements of "the old way" are not
in any way enforced, however, I think the events-will-be-fired-for-any-supported-EventListener-interface
behavior of "the new way" are reasonable, particularly if [lang] supplies a class to make
it easy to manage that type thing as I plan to.

Thoughts?

-Matt

On Jul 22, 2010, at 1:38 PM, James Carman wrote:

> Yes, that's what we're (so far Matt and me) suggesting.  There's no
> need for an abstract superclass here.
> 
> On Thu, Jul 22, 2010 at 2:34 PM, Paul Benedict <pbenedict@apache.org> wrote:
>> Sorry about "no-op" implementation.. I meant default implementation. I
>> believe a worthy goal would be to use EventListenerSupport out of the box,
>> if possible, and allow subclassing for further customization.
>> 
>> On Thu, Jul 22, 2010 at 1:29 PM, James Carman <james@carmanconsulting.com>wrote:
>> 
>>> I think we're leaning toward just having EventListenerSupport.
>>> 
>>> On Thu, Jul 22, 2010 at 2:27 PM, Paul Benedict <pbenedict@apache.org>
>>> wrote:
>>>> I have a philosophical problem with EventListenerSupport extending
>>>> AbstractEventSupport. I look at the class names, and I ask what does the
>>>> concrete class do that AbstractEventSupport doesn't? I say either provide
>>>> one abstract class, or one concrete class, but not both.
>>>> 
>>>> On Thu, Jul 22, 2010 at 1:23 PM, Matt Benson <gudnabrsam@gmail.com>
>>> wrote:
>>>> 
>>>>> Paul:  As of now there are two options.  The first is to remove
>>>>> AbstractEventSupport in favor of EventListenerSupport.  The second is
>>> for
>>>>> EventListenerSupport to extend AbstractEventSupport.
>>>>> 
>>>>> -Matt
>>>>> 
>>>>> On Jul 22, 2010, at 1:21 PM, Paul Benedict wrote:
>>>>> 
>>>>>> I looked at both in SVN and see convergence and not too much
>>> difference.
>>>>> Can
>>>>>> you guys agree to removing one? Which one? I know the classes are
not
>>>>>> identical, but they are similar enough to go "hmmm".
>>>>>> 
>>>>>> On Thu, Jul 22, 2010 at 1:17 PM, Matt Benson <gudnabrsam@gmail.com>
>>>>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> On Jul 22, 2010, at 1:11 PM, Paul Benedict wrote:
>>>>>>> 
>>>>>>>> Does EventListenerSupport provide anything useful besides
a no-op
>>>>>>>> implementation?
>>>>>>>> 
>>>>>>> 
>>>>>>> EventListenerSupport does.  AbstractEventSupport IMO provides
little
>>>>> over
>>>>>>> ELS:  an Object event source, which in my experience is not
>>> necessarily
>>>>> the
>>>>>>> greatest paradigm to emulate anyway.
>>>>>>> 
>>>>>>> -Matt
>>>>>>> 
>>>>>>>> On Thu, Jul 22, 2010 at 12:49 PM, James Carman
>>>>>>>> <james@carmanconsulting.com>wrote:
>>>>>>>> 
>>>>>>>>> On Thu, Jul 22, 2010 at 1:43 PM, Matt Benson <gudnabrsam@gmail.com
>>>> 
>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> My point was that one could just as easily add these
methods to a
>>>>>>>>> subclass of EventListenerSupport.  :)
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> +1, agree with Matt here.  Why not just extend EventListenerSupport
>>>>>>>>> and add your custom fire* methods there?  But, if you
don't want to
>>>>>>>>> add custom fire methods (and you really don't need to
with the
>>> proxied
>>>>>>>>> fire() method), then you can just use the EventListenerSupport
>>> class
>>>>>>>>> directly.
>>>>>>>>> 
>>>>>>>>> 
>>> ---------------------------------------------------------------------
>>>>>>>>> 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