[Bug 20158] Unrestricted typed dictionary

# bugzilla at jessica.w3.org (5 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

Boris Zbarsky bzbarsky@mit.edu changed:

       What    |Removed                     |Added

             CC|                            |bzbarsky@mit.edu

--- Comment #1 from Boris Zbarsky bzbarsky@mit.edu ---

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...

Contact us to advertise here
# bugzilla at jessica.w3.org (5 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

Tab Atkins Jr. jackalmage@gmail.com changed:

       What    |Removed                     |Added

             CC|                            |jackalmage@gmail.com

--- Comment #2 from Tab Atkins Jr. jackalmage@gmail.com ---

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.

# bugzilla at jessica.w3.org (5 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

--- Comment #3 from Boris Zbarsky bzbarsky@mit.edu ---

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...

# bugzilla at jessica.w3.org (5 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

--- Comment #4 from Tab Atkins Jr. jackalmage@gmail.com ---

Afaik, enumeration order should be generally interoperable now. I think the only real problem is order of numeric keys relative to non-numeric?

# bugzilla at jessica.w3.org (5 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

--- Comment #5 from Boris Zbarsky bzbarsky@mit.edu ---

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.

# bugzilla at jessica.w3.org (5 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

Nasserbufahad@gmail.com changed:

       What    |Removed                     |Added

             OS|All                         |Windows 3.1
# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

Anne annevk@annevk.nl changed:

       What    |Removed                     |Added

     Depends on|                            |16491

--- Comment #6 from Anne annevk@annevk.nl ---

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...

# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

--- Comment #7 from Boris Zbarsky bzbarsky@mit.edu ---

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.

# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

--- Comment #8 from Anne annevk@annevk.nl ---

Good point. In that case maybe dictionary<EventListener> is better syntax.

# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

Robin Berjon robin@w3.org changed:

       What    |Removed                     |Added

             CC|                            |robin@w3.org

--- Comment #9 from Robin Berjon robin@w3.org --- (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 };

# bugzilla at jessica.w3.org (3 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

Bug 20158 depends on bug 16491, which changed state.

Bug 16491 Summary: Add simpler and better event registration system www.w3.org/Bugs/Public/show_bug.cgi?id=16491

       What    |Removed                     |Added

         Status|NEW                         |RESOLVED
     Resolution|---                         |LATER
# bugzilla at jessica.w3.org (3 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

--- Comment #10 from Anne annevk@annevk.nl ---

In 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?

# bugzilla at jessica.w3.org (8 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

Jeffrey Yasskin jyasskin@gmail.com changed:

       What    |Removed                     |Added

             CC|                            |jyasskin@gmail.com

--- Comment #11 from Jeffrey Yasskin jyasskin@gmail.com ---

Web Bluetooth wants keys of type unsigned short in one case, and (unsigned long or <complicated constrained DOMString>) in the other. If we can do something

that handles numeric keys and unions of a numeric and a string type, it would be awesome, but Web Bluetooth can also handle the key conversions in prose.

# bugzilla at jessica.w3.org (8 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

--- Comment #12 from Boris Zbarsky bzbarsky@mit.edu ---

You want your key conversions in prose anyway, I'd think. If IDL were doing the conversion for you, then an unsigned short key, faced with this input:

{ hello: "I am here" }

would produce a key of 0, whereas I'm fairly sure your desired behavior is to skip this key altogether.

Oh, and the (unsigned long or DOMString) case would also not work as you expect, because the value would start off as a string in ES land, and heycam.github.io/webidl/#es-union will pick string over unsigned long given a String-typed input (but will coerce to the unsigned long if the union has no string types in it and the input is a String....)

# bugzilla at jessica.w3.org (8 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

--- Comment #13 from Anne annevk@annevk.nl ---

The other thing we need is unrestricted dictionaries with some preset members for web animation. Sam Weinig dubbed these half-open dictionaries in bugs.webkit.org/show_bug.cgi?id=158509#c14.

Strawman elaborate syntax:

open dictionary<keytype, valuetype> DictionaryName { memberType member; }

Shorthand:

open dictionary<valuetype> DictionaryName;

would be short for

open dictionary<DOMString, valuetype> DictionaryName;

which is short for

open dictionary<DOMString, valuetype> DictionaryName {};

We could maybe leave out the open keyword and just rely the <> syntax to

indicate this. Either seems fine.

keytype should probably be restricted to string and numeric types (or just string types).

# bugzilla at jessica.w3.org (8 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

--- Comment #14 from Boris Zbarsky bzbarsky@mit.edu ---

Or we could just do web animation in prose and not try to shoehorn it into here. Unless we think others will want that sort of thing too?

# bugzilla at jessica.w3.org (8 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

--- Comment #15 from Jeffrey Yasskin jyasskin@gmail.com ---

If we have numeric keys, would it make sense to support [EnforceRange]?

In order to have union keys, we'd have to use a different algorithm from heycam.github.io/webidl/#es-union, in order to prefer non-string types over strings. I can certainly do without it, but it does seem possible.

# bugzilla at jessica.w3.org (8 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

--- Comment #16 from Boris Zbarsky bzbarsky@mit.edu ---

And note that the obvious way of doing half-open dictionaries doesn't match the processing model the web animations spec defines right now.

# bugzilla at jessica.w3.org (8 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

--- Comment #17 from Anne annevk@annevk.nl ---

Fixing [EnforceRange] is bug 28834. I think the easiest thing to do here is to only deal with the three types of string keys (we have a couple of use cases for each) and leave other types of keys to prose. At least until the numeric key thing becomes more common.

# bugzilla at jessica.w3.org (8 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

--- Comment #18 from Jeffrey Yasskin jyasskin@gmail.com ---

It works for me to not have numeric keys for now.

Looking at Anne's syntax, it doesn't let me have a field of open-dictionary type without also giving that type a name. Do y'all want that restriction?

If we initially don't need to support half-open dictionaries for web animation, and 2-token types give other people the same willies they give me, how about "dictionary<keytype, valuetype>", with the first argument defaulting to

DOMString? I'm nervous about defaulting initial arguments, but it looks clear in this case.

I haven't looked into parsing this. Will re-using "dictionary" as a type instead of a type introducer cause problems? If it will, then OpenDictionary<key, value> could work.

In the future, if we want to add half-open dictionaries, would:

dictionary BasePropertyIndexedKeyframe : dictionary<(DOMString or sequence<DOMString>)> { DOMString easing = "linear"; CompositeOperation composite; };

make people happy? We'd have to write an explicit rule to override "The identifier of a dictionary member must not be the same as that of another dictionary member defined on the dictionary or on that dictionary’s inherited dictionaries."

If nobody objects, I'll send WebIDL a patch to add this.

# bugzilla at jessica.w3.org (8 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

--- Comment #19 from Anne annevk@annevk.nl ---

For everyone following along at home, heycam/webidl#180 has a patch for this that is close to being finished. If you have any particular requirements, now would be a good time to air them.

# bugzilla at jessica.w3.org (8 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=20158

Tobie Langel tobie.langel@gmail.com changed:

       What    |Removed                     |Added

     Resolution|---                         |FIXED
         Status|NEW                         |RESOLVED

--- Comment #20 from Tobie Langel tobie.langel@gmail.com ---

Fixed by heycam/webidl/commit/1814384

Want more features?

Request early access to our private beta of readable email premium.