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: <3F8AE1D7.1070002@phreaker.net>
Date: Mon, 13 Oct 2003 10:33:11 -0700
From: __matthewHawthorne <matth@phreaker.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5b) Gecko/20030901 Thunderbird/0.2
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [primitives] Package layout strategy
References: 
 <73E71EF16978D51197180002A56022D20743CB09@ngmnt4mbx03.uk.capitalone.com>
 <3F8AD82D.2050807@phreaker.net> <20031013100323.F80134@minotaur.apache.org>
In-Reply-To: <20031013100323.F80134@minotaur.apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

The problem is: how to properly package the massive amount of primitive 
collection classes.  I see this as a valid problem.  Leaving well enough 
alone is a possibility, another is to discuss if there are better 
options.  That's what is taking place here.

Waiting until there is a real-world use-case for primitive Maps is an 
option.  However, since many of the other collection types have been 
covered, I think that basic Map implementations are a necessity for a 
release.  Now, the amount of Maps could be many, in which case it may be 
wise not to get too deep into ordering and other algorithms and types. 
Having real world users of these classes would be nice, but given the 
nature of the classes, I don't think it would have much affect on the 
outcome, it all seems pretty monotonous.  That's why a lot of the code 
can be generated.

I don't think that every class in commons had a use case before it was 
created.  When thinking about possible additions, I'm sure that a lot of 
brainstorming occurs.  This may have both good and bad effects.  But as 
long as the code is documented well, and has test cases, I don't see 
this as a big deal.


Rodney Waldhoff wrote:

> On Mon, 13 Oct 2003, __matthewHawthorne wrote:
> 
> 
>>I believe that there will be a lot of code generation involved, Stephen
>>checked in some Velocity templates a few weeks ago.
> 
> 
> Rather than generating the 64 pairwise primitive-to-primitive maps, their
> associated iterfaces, base classes, adapaters, decorators (immutable,
> sychronized) and variations (ordered/unordered, hash/tree, etc.), why not
> wait until we have an actual, real-world application that calls for them?
> 
> 
>>So the battle has become:
>>
>>o.a.c.primitives.boolean
>>o.a.c.primitives.byte
>>o.a.c.primitives.short
>>o.a.c.primitives.int
>>o.a.c.primitives.long
>>o.a.c.primitives.float
>>o.a.c.primitives.double
>>
>>vs.
>>
>>o.a.c.primitives.collection
>>o.a.c.primitives.list
>>o.a.c.primitives.iterator
>>o.a.c.primitives.map
>>
>>
>>Any other opinions?
>>
> 
> 
> Yes, leave well enough alone.  Again, what problem are we trying to solve?
> 


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