commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [collections] Primitive sub package
Date Wed, 08 Jan 2003 00:55:56 GMT
From: "Rodney Waldhoff" <>
> > I've taken a look at the code added to the primitive package. It looks
> > from my fairly quick scan reading. How do you feel about it though? Do
> > reckon that the primitive only class plus object wrapper idea is the
> > one now that you've actually got some code going in it? I guess the main
> > advantage is focussing peoples minds on the fact that they are primitive
> > lists and not losing the performance gain in boxing.
> Yes, the collections.primitives.* offers time and space improvements over
> the wrapped alternative.  You may want to see the early commons-dev
> discussions on this topic.

I understand the perfomance/space benefits. I was wondering if you felt the
redesign from the now deprecated primitive classes was beneficial? I think
it is, but it still doesn't feel quite right. Maybe its just new.

> > 2) Primitive collections will typically be based around an array, and so
> > be bound (fixed size). For Objects, we have a BoundedCollection
> > that defines isFull() and maxSize(). Perhaps these should be methods on
> > IntCollection?  (We don't have to stick to the JDK spec ;-)
> None of the current implementations are bounded (which doesn't rule out a
> BoundedIntCollection in the long run).

However, once released, the interface becomes fixed and we have to resort to
hacks like BoundedCollection. These two methods could be implemented by all
collections (isFull() == false, maxSize == Integer.MAX_INTEGER for
non-bounded collections) easily. I think its probably worth doing.

> > 3) Similarly, one feature that people have requested in iterators is the
> > ability to reset them. So maybe IntIterator should have a reset() method
> > that resets it to the start again.
> That makes the Iterator/<Primitive>Iterator adapters difficult to
> implement, but may be suitable for a sub-interface.  (I love reset-able
> iterators, by the way, cf.
> which is a major consumer of the primitive collections.)

I think we should try to solve the difficulty problem and add reset() to
IntIterator. I was thinking of adding a ResetableIterator interface to
[collections] (Objects area) anyway, as a number of our interfaces implement
reset() and it would be useful to be able to identify them.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message