Combination of the proposals:
public interface MapIterator extends Iterator {
/** Is there another key to iterate to */
boolean hasNext();
/** Get the next key */
Object next();
/** Get the value associated with the last key retrieved from next() */
Object getValue();
/** Set the value associated with the last key retrieved from next()
OPTIONAL*/
void setValue();
/** Remove the last entry returned by next() OPTIONAL */
void remove();
/** Get a Map.Entry implementation for the last key retrieved */
Map.Entry getMapEntry();
}
public interface ResetableIterator extends Iterator {
/** Reset the iterator back to the start */
void reset();
}
MapUtils would have a getMapIterator(Map) method which checks for either an
IterableMap instance, or creates a simple instance wrapping
entrySet().iterator().
All our existing Map implementations would be extended to directly support
IterableMap.
I still kindof feel that there should be a getKey() on MapIterator, although
it would duplicate next().
I understand the problem with reset() not always being supportable now.
Any advantage in defining
isSettable()
isRemovable()
on the interface? Not very collections like but perhaps useful.
Stephen
----- Original Message -----
From: "Rodney Waldhoff" <[EMAIL PROTECTED]>
> On Wed, 8 Jan 2003 [EMAIL PROTECTED] wrote:
>
> > > from: Rodney Waldhoff <[EMAIL PROTECTED]>
> > >
> > > * 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();
> }
>
> or,
>
> 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:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
