Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
Message-ID: <3E635000.6070706@apache.org>
Date: Mon, 03 Mar 2003 07:52:16 -0500
From: Berin Loritsch <bloritsch@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: Avalon Developers List <dev@avalon.apache.org>
Subject: Re: Hierarchy.java
References: <20030228225253.40721.qmail@icarus.apache.org>
 <3E5FFF59.9020908@apache.org> <3E6036A6.2070601@apache.org>
 <200303011603.33579.peter@realityforge.org>
In-Reply-To: <200303011603.33579.peter@realityforge.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Peter Donald wrote:
> On Sat, 1 Mar 2003 15:27, Stephen McConnell wrote:
> 
>>Stephen McConnell wrote:
>>
>>>Peter:
>>>
>>>There was discussion on the subject of log listener related methods
>>>prior to the release of logkit during which it was my understanding
>>>that the add/remove listener was the preferred approach over a set
>>>approach. 
> 
> 
> Not preferred by me. Mind numbingly stupid I thought but that is to be 
> expected when the people who are "designing" the functionality don't even 
> know what the use case is.


Peter, you have been presented many opportunities to present your use
cases.  You never did.  You also circumvented the way we do things in
Avalon.  Things like that require consensus, and I do not recall you
even bringing it up.  I like you on many levels, but what we came up
with was a compromise.  We need to live with it even if it is
sub-optimal.

I highly recommend that you revert your change, because it slaps the
community in the face.  You could have been part of the discussion
when it was being added in a more constructive way.  I put it in there
the way you had it--which sparked community discussion.  The community
decided that they preferred the method that is currently there.

Also, you need to think of our users.  If a method is introduced in
one release, and then deprecated in the next--with no clear technical
advantage--then they will start to get fed up with our stuff.  I
personally don't want to see that happen.

-1 to the change, esp in the manner in which it was done.

Feel free to put your use cases on the table.


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