This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Context: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/thread.html#msg220 URLQuery constraints: URLQuery represents an ordered list of name/value pairs and within that list duplicate names can occur. URLQuery API propopal: * new URLQuery(object) creates an ordered list of name/value pairs. We might want to support sequenced values in the object so you can create duplicate names. * get(name) gets the value of the first matching name. * getAll(name) gets all values. * set(name, values) gets the matching items from the list and from that new list replaces their values one by one. If there's values left, appends new items to the list. If there's too few values, removes items from the list. * add(name, values) ads new name/value pairs to the list. * has(name) same semantics. * delete(name [, value]) deletes all of name, or only removes those with a matching value. name/value are also constrained in what they can contain. Percent-encoding happens for both. In addition URLQuery directly manipulates the query string of the associated URL object. (I'm not entirely happy with the set() semantics above. Maybe initially we should only support setting a single value and require add() for duplicates?)
Note that URLQuery isn't strictly a Map - it's a MultiMap, where one key can map to multiple values. As such, we should probably check with tc39 to see if they have plans for a MultiMap API after Maps are fully adopted, and be consistent with that. If they don't, we should at least make sure that the Map functions act appropriately for a single-value Map, and have additional functions for treating as a MultiMap (as you say, make set() take only a single value, while add() adds more values).
Also, while we're doing this, we should check to see if there are any use-cases in the DOM for ES Sets, and add that at the same time.
I changed my mind a little bit relative to comment 0 (API is also changing somewhat per discussion with Tab, see http://url.spec.whatwg.org/ for the latest thinking in a couple of hours). name/value will just be type constrained. The encoding and decoding of name/value will only happen when interfacing with the other object the ordered MultiMap needs to keep in sync with.
Seems, for URLQuery API a "LinkedListMultiMap" is required. - something similar to http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/collect/LinkedListMultimap.html for proper iteration order when serializing
This use case has been solved through other means.