Bug 20158 - Unrestricted typed dictionary
Summary: Unrestricted typed dictionary
Status: NEW
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC Windows 3.1
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on: 16491
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-29 14:54 UTC by Anne
Modified: 2014-06-16 16:06 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anne 2012-11-29 14:54:32 UTC
For constructing URLQuery it would be nice to allow an object whose keys are strings and values are either strings or a string sequence, with no restrictions on what the keys have to be and such.
Comment 1 Boris Zbarsky 2012-11-29 16:09:33 UTC
How would you define such a thing interoperably?

Having explicit names for keys in dictionaries means that the IDL author also defines an explicit order on the keys.  But if you allow arbitrary names, what's the key order?  Note that key order matters when getters with side-effects are involved...
Comment 2 Tab Atkins Jr. 2012-11-29 17:30:37 UTC
Key order matters in general for this use-case, too, since the object gets translated into a series of set() calls on the URLQuery object, which maintains ordering internally.
Comment 3 Boris Zbarsky 2012-11-29 17:33:36 UTC
One option is to just say that key order is determined by the passed-in object and define that in the ES binding this is enumeration order.  Of course enumeration order on objects is not actually the same across UAs, and if you have the temerity to use numeric keys (including "2" and whatnot) you can't control their enumeration order at all in some ES impls and in the ES6 spec...
Comment 4 Tab Atkins Jr. 2012-11-29 17:38:02 UTC
Afaik, enumeration order should be generally interoperable now.  I think the only real problem is order of numeric keys relative to non-numeric?
Comment 5 Boris Zbarsky 2012-11-29 17:40:26 UTC
> Afaik, enumeration order should be generally interoperable now. 

It's interoperable for keys that don't look like numbers. There's pretty much no interop for the ones that do.  It's not just numeric vs non-numeric; the order of the numeric keys is different in different implementations, and sometimes within a given implementation for different objects.
Comment 6 Anne 2013-01-04 22:51:19 UTC
So URLQuery wants a dictionary that's a collection of string->string. Bug 16491 wants a dictionary that's a collection of string->callback.

Syntax proposal:

unrestricted dictionary { DOMString EventListener };

Using enumeration order and hoping that at some point ES will define that works for me...
Comment 7 Boris Zbarsky 2013-01-05 01:21:13 UTC
Are there ever use cases that want keys other than strings?  If not, it seems like all that's needed is a type for the value.
Comment 8 Anne 2013-01-05 11:57:20 UTC
Good point. In that case maybe dictionary<EventListener> is better syntax.
Comment 9 Robin Berjon 2013-01-07 09:58:31 UTC
(In reply to comment #8)
> Good point. In that case maybe dictionary<EventListener> is better syntax.

I tend to agree. But if ever there is a need for non-string keys, your initial syntax would need a separator to disambiguate:

  unrestricted dictionary { long long long };
Comment 10 Anne 2014-06-16 16:06:19 UTC
In http://fetch.spec.whatwg.org/#headers-class I went with OpenEndedDictionary<ByteString> but I can definitely migrate to the syntax from comment 8.

I briefly discussed constrained keys with bz. It seems keys would mostly be DOMString, but FormData, URLSearchParams, and Headers all have usage for constrained keys. The first two want ScalarValueString, the last wants ByteString. We could do that in prose, but maybe we should allow the three string types at least?