Map<K, V> should extend Collection<K>

[DartBot]

This issue was originally filed by @seaneagan

---

Having Map<K, V> extend Collection<K> would obviate the need for...

1. Map.forEach(K, V):

map.forEach((key, value) => foo(key, value);
// becomes
map.forEach((key) => foo(key, map[key]);

2. Map.getKeys:

map.getKeys().{every,some,filter,etc.}(...)
// becomes
map.{every,some,filter,etc.}(...)

3. Map.{length,isEmpty}

These just become Collection.{length,isEmpty}

This would be familiar to JS programmers since JS objects are akin to dart Map<String, Dynamic>'s, and JS has:

for(key in obj) ...

Also, it would make sense to add:

bool contains(E);

to Collection<E>, which in conjunction with this proposal would replace Map.containsKey.

Another alternative would be to have Map<K, V> extend Collection<Pair<K, V>> where Pair represents key-value pairs, but that seems more complex / less desirable.

[DartBot]

This comment was originally written by [email protected]

---

Added Area-Library, Triaged labels.

[DartBot]

This comment was originally written by [email protected]

---

While this would make some things easier, I don't think that this is the right thing to do. Is map really a collection? I certainly don't think that it is a collection of its keys, nor do I think that it is a collection of key-value pairs (although this makes some sense).

If it is worth something, I vote against this proposal. I don't think that the savings are worth the (possible) confusion.

[DartBot]

This comment was originally written by @seaneagan

---

According to http://en.wikipedia.org/wiki/Collection_(computing):

"a collection is a grouping of some variable number of data items (possibly zero) that have some shared significance to the problem being solved and need to be operated upon together in some controlled fashion"

It further mentions an example of a collection being the "associative array" (http://en.wikipedia.org/wiki/Associative_array) which is "also called a map or a dictionary".

The Collection interface provides common methods to "operate upon" the "data items" of collections. The "data items" for maps are "associations" or "ordered pairs". This argues for Map<K,V> to extend something like Collection<Pair<K,V>> rather than Collection<K>. However, the Collection interface really only consists of convenience methods for Iterables, i.e. all Iterables could be Collections if there were an easy way to "mixin" the implementation of the Collection methods. Thus, it makes sense for the generic type to correspond to whatever is most useful to iterate over. Since Map defines the [] operator to get the value of a key, there really is no need to iterate over key-value pairs, iterating over the keys is simpler, more convenient, and probably more efficient since no Pair objects need to be created.

Probably the best evidence that Map wants to be a Collection is that it defines "length", "isEmpty", and a variant of "forEach", all of which are in Collection. It doesn't define "some", "every", and "filter" probably just to avoid bloating the interface with slightly modified variants of the Collection methods, and this makes it difficult to remember which types implement them.

[DartBot]

This comment was originally written by [email protected]

---

You might also argue that map is in fact two collections at once: a collection of keys and a collection of values. That is particularly interesting when considering a "bimap" in which you can get values by keys and also keys by values.

I'd say that probably the best evidence that Map shouldn't be a Collection is the fact that there are too many ways of doing it and all of them makes some sense (either from theoretical or practical point of view). You can have your collection of keys just by calling .getKeys(), that isn't too hard (and it probably could be a getter, that would make it even more easier).

[DartBot]

This comment was originally written by [email protected]

---

#­1 Implies that keys are unique within the map. Then wouldn't it be more correct to say that Map<K, V> should extend Set<K>?

If Map<K, V> extends Collection<Pair<K, V>>, it makes it easier to extend Map to Multimap.

[DartBot]

This comment was originally written by @seaneagan

---

@4: Having Map<K, V> extend Collection<K> actually supports "BiMap" as a subtype of Map quite well. BiMap would just need to specialize the return type of "getValues()" (which could be shortened to "values") to BiMap<V, K>.

@5: Having Map<K, V> extend Set<K> or Set<Pair<K, V>> would be awesome. If MultiMap<K, V> were added, it should be in between Set<Pair<K, V>> and Map<K, V>:

interface MultiMap<K, V> extends Set<Pair<K, V>> {
  MultiMap<V, K> get inverse();
  Collection<K> get keys();
  Collection<V> get values();
}

interface Map<K, V> extends MultiMap<K, V> {
  Set<K> get keys(); // keys are unique
  //...
}

interface BiMap<K, V> extends Map<K, V> {
  BiMap<V, K> get inverse(); // inverse is also a BiMap (and thus Map)
  Set<V> get values(); // values are unique
}

[lrhn]

Map is not a collection. Its keys might be a Set. I'd prefer to have a Set view of the keys, backed by the Map. Example:
  class Map<K,V> {
    ...
    /** Returns a live view of the keys of this [Map].*/
    Set<K> get keys;
    /// ditto values
    Collection<V> get values;
  }

Also: Favor composition over inheritance!
A Map has a set of keys, it is not a set.

A view as Set of Pair is also possible.

---

Added WontFix label.

[DartBot]

This comment was originally written by @seaneagan

---

Something like:

Set<Pair<K, V>> get pairs;

should be sufficient.

For the keys/values getters, see issue #1248.