As I expressed in an earlier thread to es-discuss, Anne van Kesteren
is currently writing the URL spec, and as part of that he's designing
the URLQuery interface, which is essentially a MultiMap (a Map where
one key can map to multiple values).  I was convinced in the previous
thread that trying to make a MultiMap a subclass of Map was a red
herring, and that MultiMap should instead be a parallel class to Map,
like Set is.

So, I've been working with Anne to design the URLQuery interface
against a speculative future MultiMap API.  I figured it would be a
good idea to run it against es-discuss before we settle on it.  ^_^

Note that right now, we've trimmed down the MultiMap features of
URLQuery to the bare minimum necessary (getAll and append), to avoid
forcing tc39's hand as much as possible.

Our approach is that MultiMap should be able to masquerade as a Map,
adding the additional functionality in overloads or variant functions.
 Conceptually, imagine the MultiMap as an ordered list of (k,v) pairs,
with no restriction (compare to Map, which places a restriction that
there are no pairs with the same k).

get(k) => returns the value of the first (k,_) pair, or else undefined.
getAll(k) => returns a (possibly empty) array of all values associated
with the key

set(k,v) => finds the first (k,_) pair, and replaces its value with v.
Removes any other (k,_) pairs. If there were no (k,_) pairs, adds
(k,v) to the end of the map.
setAll(k, [v]) => replaces (k,_) pairs until either the input list or
the existing pairs runs out. Removes any other (k,_) pairs. If there
were leftover values, adds (k,v) pairs to the end of the map.

append(k,v) => adds (k,v) to the end of the map.
appendAll(k,[v]) => adds multiple values.  Needed?

has(k, v?) => return true/false if a (k,_) pair is in the map. If the
second arg is provided, returns true/false if (k,v) is in the map.

delete(k, v?) => removes all (k,_) pairs from the map.  If the second
arg is provided, removes only the (k,v) pairs.

For iterators, obviously keys() would only return unique keys.  Unsure
whether values() should return individual values, or arrays of values
associate with each key (and same for items()).  I lean toward the
latter, so that the iterators returned by keys() and values() are
comparable (zipping them gets you the same value as calling items()).
Would we want a second items()-like iterator that returns the
individual (k,v) pairs?

Thoughts?

~TJ
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to