> from: Rodney Waldhoff <[EMAIL PROTECTED]> > 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". My mistake in the typing, I meant Object next(); In fact it will make more sense for this to return the key (see other email).
> * 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.] > * 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? > * 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. This is the most controversial part of the design, and actually not that important. I would happily remove the "implements Map.Entry", but still keep the methods. Stephen > 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. (see above for comment) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
