What is to be served by a map of short --> Object, that isn't also served by int --> Object? Yes, there might be a *slight* improvement in memory use, but little else, so far as I can tell, with the possible exception of primitive type safety.
The converse question applies as well. What gain is there of int --> short? Why not just use int --> int? The case of int --> boolean is really just a degenerate case of int --> Object, where Object is a Boolean.TRUE or Boolean.FALSE, isn't it?
Is there any value whatsoever to boolean --> X?
For primitive maps, I see the interesting key types as int, long, double, and destination types as int, long, double, and Object. If you really argue the point, you might further boil this down to just long and double, but that really could consume lots more memory, at least where short keys are concerned.
All of which might argue for defering the creation of these map classes until needed.
-Eric Johnson
__matthewHawthorne wrote:
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
