Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <3D64F928.9010207@apache.org>
Date: Thu, 22 Aug 2002 16:46:00 +0200
From: Nicola Ken Barozzi <nicolaken@apache.org>
Reply-To: nicolaken@apache.org
Organization: Apache Software Foundation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [VOTE] (re-vote) XxxUtils constructors
References: <Pine.LNX.4.33.0208221014050.5644-100000@umbongo.flamefew.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Henri Yandell wrote:
> 
> On Thu, 22 Aug 2002, Nicola Ken Barozzi wrote:
> 
> 
>>Henri Yandell wrote:
>>
>>>It's an issue whenever you submit code to anywhere. The maintainers of the
>>>code once submitted do not have solely your interests at heart and are not
>>>able to predict exactly where you want to take the code in the future.
>>
>>" do not have solely your interests at heart "
>>
>>Sometimes it seems like "do not have your interests at all".
> 
> 
> Sure. Within the context of a disagreement it will seem that way.
> 
> 
>>>On the other side, the submitter is no longer having to maintain the code.
>>
>>But has to fight battles to even small changes to the code that the
>>submitter needs.
> 
> 
> They're welcome to join up.
> 
> 
>>These are utility classes, not core stuff, the hell with perfection and
>>purity.
> 
> 
> Can I quote this? I want to put this in javadoc at the top of each
> class :)

Sure ;-)

>>>If projects that submit code, Jakarta or not, were using bad concepts in a
>>>piece of code that is submitted, then improvement by Commons would be a
>>>*big* success and not a big failure. The only issue here is that there is
>>>debate over whether it is an improvement.
>>
>>Commons should never deal with "bad concepts", only "unfunctional code".
>>
>>If it works, good, if it doesn't, no good.
>>Leave "politics" to real projects.
> 
> 
> I'll put this down to being pissed off. Not allowing Commons projects to
> attempt to create commonality between the components that are submitted
> is a mistake.

Commonality, I never said I'm against this.

">>If it works, good, if it doesn't, no good."

means

"If it works *for all*, good, if it doesn't, no good."

>>>Can you point everyone to the threads on this subject on the submitting
>>>projects in which they discussed not having a private constructor on those
>>>classes, or was it just so obvious that no one ever questioned it?
>>
>>If I submit code that I use, I want to be able to switch to the new
>>common version.
>>But if it becomes something that I cannot use anymore, my donation was
>>useless.
> 
> 
> Useless to the submitter yes. I don't think anyone is looking for a system
> in which you cannot use the submitted code anymore. So far you've listened
> to a lot of people who believe fervently in a private() trying to figure
> out a solution that encompasses their belief in a thinner API for
> stability [my interpretation] and the need for instance manipulation.
> 
> 
>>It's about deafness over feature requests from the projects that
>>submitted the code.
>>Commons must listen to the users, not dictate behaviour.
> 
> 
> Listen to users +1. Is this whole thread not an exercise in listening to
> the user?

No, it's an exercise in showing the user that their project does bad 
things, and that it must change tactics if it wants to use the code it 
donated.

I would call this "respect".

> Not dictate behaviour. -1. The only way I can see this happening is
> by:
> 
> a) Having a package per user's submission.
> b) Never adding anything new.
> c) Allowing only the user who submitted to edit the code.

Nope.
It's about not making the code unusable from a project that uses it 
without having to change itself.

Dictating is about having other projects do what Commons says instead of 
the opposite *even* when there is no need for it, and this need comes 
from different projects having clashing needs.

IE: If I have two projects that have a "Utility" class with many common 
things and a methid with different return types, *that* is a problem 
that Commons can help resolve.

>>Have a nice day, you all.
>>
>>I hope the Velocity guys stop discussing this and get their forked
>>version working.
>>Maybe one day they will still be able o switch to the commons version.
> 
> I thought the Commons guys were discussing this. We should move the
> conversation over to Commons-User then. *relatively intended tongue in
> cheek*

You are defending a position as a mediator, not a strenuous "public" 
opponent.
My remarks are always about the bad attitude to compromise that many 
Commons devs have, which I haven't yet found in you; we are going on 
well with the Avalon stuff :-)

>>In the meantime, I better start thinking of a commons/private2public
>>project that changes automatically private constructors to public when
>>loading classes if I want to be free with my code...
> 
> Cool. Could you use it on java.lang.Math, java.util.Collections,
> java.util.Arrays, java.x.x.x. I'd like to use them from Velocity.
> The alternative would be that some project of reusable objects for
> java.lang and java.collections could create bean wrappers to solve this
> problem, if it were deemed necessary.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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