commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <>
Subject Re: [collections][PROPOSAL] MapIterator and IterableMap
Date Wed, 08 Jan 2003 15:56:14 GMT
On Wed, 8 Jan 2003 wrote:

> >  from:    Rodney Waldhoff <>
> >
> > * Mixing next() and getKey()/getValue() into the same interface seems to
> > be mixing metaphors.
> Its actually the key to the reason for the class. Maps perform badly
> because a Map.Entry has to be created each time around the loop (unless
> you store Map.Entry objects internally, and I don't want to do that).
> [Imagine that you want to store the objects internally in two arrays
> rather than one array of Map.Entry objects] An entrySet iterator is much
> slower than a MapIterator in this case due to the need to create the
> Map.Entry objects on the fly.]

Then I think you want an interface that doesn't imply the creation of the
key/value pair, perhaps wholly independent of the Iterator and Map.Entry
interfaces.  For example, maybe something ResultSet like:

interface MapIterator {
  boolean advance();
  Object getKey();
  Object getValue();
  // optionally adding:
  Map.Entry getMapEntry();


interface MapIterator extends Iterator {
  /** Returns the next key, if any */
  Object next();
  /** Returns the value associated with the "current" key */
  Object getValue();

The latter is similiar to Henri's example that you labeled "#3", although
that one should not that's not quite the same Iterator you'd get from
Map.keySet().iterator(), in the case of Maps that allow duplicate keys.
Either would be trivial to implement for Maps that support
entrySet().iterator() as well as Maps whose internal representation is a
pair of lists or arrays.

> > * Not every [Map]Iterator is going to be able to support reset(), which
> > requires us to make reset() an "optional operation".  A ResetableIterator
> > interface seems like a more elegant handling of doing this, since it
> > advertises when an Iterator supports reset.
> Why can't every IterableMap support reset()? It just requires holding a
> reference to the original collection doesn't it?

No.  Some Iterators are not directly associated with a Collection (or Map)
or even a factory for creating said iterator.  Consider, for instance:

  /** Returns an Iterator over the tokens in the given StreamTokenizer. */
  Iterator tokenIterator(StreamTokenizer);

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

View raw message