commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [lang] EventListenerSupport type variable Re: [VOTE] Release Commons Lang 3.0 Beta.1
Date Mon, 26 Jul 2010 17:13:51 GMT
I wouldn't do it.  Folks don't necessarily extend EventListener,
although they should.  I think it's adding restriction without adding
too much value.  If EventListener had some methods on it that we
depended on then that would be a different story.

On Mon, Jul 26, 2010 at 12:16 PM, Michael Wooten <mwooten.dev@gmail.com> wrote:
> +1 to restricting the type.
>
> On Mon, Jul 26, 2010 at 12:05 PM, Matt Benson <gudnabrsam@gmail.com> wrote:
>> To try and get this whole subject put to bed, is anyone opposed to restricting the
bounds of EventListenerSupport's <L> variable to <L extends EventListener>?  It's
not strictly necessary, but without the restriction, the listener semantics of the ELS class
itself are completely superficial, in which case why wouldn't we just rename the class CompositeManager,
put it in a different package, and make its method names more generic?
>>
>> -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
>>
>>
>
> ---------------------------------------------------------------------
> 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