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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
