commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [VOTE] Release Commons Lang 3.0 Beta.1
Date Thu, 22 Jul 2010 18:29:02 GMT
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


Mime
View raw message