I like the general idea, but I think that interface is broken in a number
of ways:
* Java doesn't allow covariant return types, so you can't actually declare
"Map.Entry next();" and "extends Iterator".
* Mixing next() and getKey()/getValue() into the same interface seems to
be mixing metaphors.
* 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.
* Having the MapIterator extend Map.Entry (and return itself for next())
seems like an implementation detail (i.e., something that shouldn't be
part of the interface), and a questionable one at that. If MapIterator
extends Map.Entry, then each call to MapIterator.next() should change the
equals() and hashCode() (implementing Map.Entry), but that also changes
the values of the MapIterator. Similiarly:
MapIterator iter = map.mapIterator();
Map.Entry first = iter.next();
Map.Entry second = iter.next();
doesn't work in this scenario, since the second call to iter.next()
changes the value of the Map.Entry returned by the first such call.
I think "IterableMap" sounds great. But other than declaring that the
returned object iterates over Map.Entrys, I don't see any advantage to the
new interface. In other words, I'd implement:
public interface IterableMap extends Map {
Iterator mapIterator();
}
and
public class MapToIterableMapAdapter implements Map {
public MapToIterableMapAdapter(Map map) {
this.map = map;
}
// ...
public Iterator mapIterator() {
return map.entrySet().iterator();
}
// ...
}
and leave it at that.
- Rod
On Wed, 8 Jan 2003, Stephen Colebourne wrote:
> I would like to propose the addition of two new interfaces to [collections].
> These are prompted by a list comment a while back that Sun defined maps "as
> a list of pairs rather than a pair of lists".
>
> (not terribly relevant but...)
> http://www.mail-archive.com/[email protected]/msg13059.html
>
> So...
> public interface IterableMap extends Map {
> public MapIterator mapIterator();
> }
> public interface MapIterator extends Iterator, Map.Entry {
> // copied from extends
> public boolean hasNext();
> public Map.Entry next(); // implementation returns the map iterator, as
> that implements Map.Entry
> public Object remove();
> public Object getKey();
> public Object getValue();
> public void setValue();
> // on this interface
> public void reset();
> }
>
> Thus:
> for (MapIterator it = map.mapIterator(); it.hasNext(); ) {
> it.next();
> doSomething(it.getKey(), it.getValue());
> }
>
> This will allow new Map implementations that are 'a pair of lists'. I have
> one in mind. For some implementations this will be much more efficient than
> using entrySet().iterator(). And an adaptor can easily be built to JDK maps.
>
> The MapIterator interface could vary from that above. One alternative is to
> not extend Iterator or Map.Entry:
> public interface MapIterator {
> public boolean hasNext();
> public Object nextKey();
> public Object removeKey();
> public Object getValue();
> public void setValue();
> public void reset();
> }
> I think that the first proposal is more generally useful however.
>
> Useful?
>
> Stephen
>
>
> --
> 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]>
