[change of plan proposed...]
Thanks for the input Rodney. It sounds like you are convinced that new Interfaces and
wrappers are the way to go. And you seem to be offering to code them :-)
However, I believe that were I to accept them into this release as a rushed quick
code, with little
Rodney, you are the main instigator of this subpackage [...]
Any objections to the remove primitives from the release plan?
If remove from the release plan simply means you'll exclude
o.a.c.c.primitives.* from the binary and source distributions--i.e., that I
don't have to do anything--then
Here's an example of a primitive collections library which uses a separate
class heirarchy and the same method names
http://trove4j.sourceforge.net/
http://trove4j.sourceforge.net/javadocs/
My 0.2 cents,
Janek Bogucki
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional
Option two fits with XP philosophy. Trim features to make the
release, rather than putting something in that doesn't measure up,
or blowing the schedule.
I'm finding this an interesting problem so I would be glad to
interact re design questions. Also, I think Bill Venners would be
interested in
There is a good body of code here, but the GNU licence rules it out I
believe.
Stephen
- Original Message -
From: Janek Bogucki [EMAIL PROTECTED]
Here's an example of a primitive collections library which uses a separate
class heirarchy and the same method names
The exclusion plan seems to be OK.
For the primitive design, my first approach would be to start with
IntCollection and IntList interfaces and work out. I think that the
interfaces can be exactly the same as the Collection and List interfaces,
but returning/taking in ints instead of Objects.
Yeah, what he said. ;)
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 15, 2002 4:29 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [collections] Primitive collections
The exclusion plan seems to be OK.
For the primitive design
I'm copying a message I just sent to Stephen:
Unfortunate. I have noted this tendency throughout Java's lifetime,
within Sun, to make decisions and not really review them because of
a percieved need to rush something out. As a result, Java is filled
with poor design decisions, and often foibles
I suspect there's a design that would allow consistent names to be
used (add(), get()), but also to be able to treat something as a
real Collection or Map. Something Proxy-ish or Adapter-ish
comes to mind; at least, some form of composition.
Sounds reasonable.
(actually, if you're using
