Specify open dictionaries. #180

jyasskin · 2016-09-30T01:22:30Z

Let me know what you think. Preview at https://rawgit.com/jyasskin/webidl/open-dictionaries/index.html.

I tried to position dictionary<K, V> as a dictionary type, but we may need to move some things from https://rawgit.com/jyasskin/webidl/open-dictionaries/index.html#idl-dictionaries to https://rawgit.com/jyasskin/webidl/open-dictionaries/index.html#idl-dictionary to really make that work.

I introduced a "mappings" term for the contents of an open dictionary, but I might be able to re-use "dictionary members".

I used <div algorithm> blocks to get better <var> checking, but that also results in boxes around the algorithms, which you might or might not like.

@bzbarsky @tobie @annevk

Preview | Diff

Per Commit Preview & Diffs

annevk · 2016-09-30T06:56:54Z

I was wondering if the enumeration logic when converting from JavaScript should be closer to step 22, substep 3 of https://html.spec.whatwg.org/multipage/infrastructure.html#structuredclone. (I'm not really sure one way or another, but since they're both copying operations.)

annevk · 2016-09-30T07:07:19Z

Also, should we revert #13 at this point? It was added at the time as some kind of proposed replacement for this, but didn't actually address the dictionary-like problem and has since gone unused.

This feature was introduced by #13, but the main thing we actually needed for Headers et al was open dictionaries (see #180). As such this feature has not seen any use.

jyasskin · 2016-09-30T07:38:22Z

index.bs

+    1.  If [=Type=](|O|) is not <emu-val>Object</emu-val>,
+        <a lt="es throw">throw a <emu-val>TypeError</emu-val></a>.
+    1.  Let |result| be a new empty instance of <code>{{dictionary}}<|K|, |V|></code>.
+    1.  Let |entries| be [=EnumerableOwnProperties=](|O|, "key+value").


@annevk I think step 22, substep 3 of Structured Clone is equivalent to EnumerableOwnProperties. There is an interesting question about what order we should type-check vs [[Get]]ing the values. I see at least four options:

Get all properties before checking their types (what I have now).

Get and check all the keys, and then interleave getting values with checking them.

Get all keys, then check a key, get its value, check its value, repeat.

Get all keys, then get a key's value, check the key, check the value, repeat.

For sane objects these are the same, but for getters with side-effects they're not.

Right, I don't have an opinion here, but I think the current approach is different when it comes to getters and I don't know what is better. I just thought I'd raise it to see if anyone else had thoughts on that.

Oh, right, StructuredClone does interleave getting with possible exceptions from the recursive StructuredClone call.

You should not use EnumerableOwnProperties here, because EnumerableOwnProperties creates an array. This mixes levels between the abstract (list/records/ES spec devices) and the concrete (Arrays), and also makes it unclear whether in subsequent steps when you do [key, value] what the exact semantics are (e.g. is it impacted by changes to Array.prototype or the iteration protocol).

I've switched to EnumerableOwnProperties("key"), which returns a List.

tobie · 2016-09-30T07:59:13Z

I used <div algorithm> blocks to get better <var> checking, but that also results in boxes around the algorithms, which you might or might not like.

We can always fix the styling if we don't like it, but we should absolutely put all algorithm in <div algorithm> blocks. I'll fix the other algorithms in the spec shortly.

You might also want to wrap your lists in <ol class="algorithm"> as this gives us the light blue left-hand border which makes visualizing nesting in algorithms much easier (this probably should be automatic within algorithm blocks but isn't for now /cc @tabatkins).

jyasskin · 2016-09-30T08:16:13Z

speced/bikeshed#759 should have made the blue border happen inside algorithm blocks, and it's working in Web Bluetooth. I'm not sure what's different here.

tobie · 2016-09-30T08:48:38Z

index.bs

@@ -5171,6 +5175,7 @@ type.
        "DOMException" Null
        BufferRelatedType Null
        "FrozenArray" "&lt;" Type "&gt;" Null
+        "dictionary" "&lt;" Type "," Type "&gt;" Null


You probably want to give it its own non-terminal to account for the first Type being optional:

<pre class="grammar" id="prod-OpenDictionaryType"> OpenDictionaryType : "dictionary" "<" Type ">" "dictionary" "<" Type "," Type ">" </pre>

Oops, done.

This feature was introduced by #13, but the main thing we actually needed for Headers et al was open dictionaries (see #180). As such this feature has not seen any use.

bzbarsky · 2016-09-30T19:53:00Z

I believe this proposed grammar is not LL(1) parseable. Specifically, OpenDictionaryType looks like a textbook example of https://en.wikipedia.org/wiki/LL_parser#FIRST.2FFIRST_Conflict. I'm willing to be proven wrong on this point, of course. ;) I think basic refactoring something like this:

OpenDictionaryType ::
    dictionary < Type OpenDictionaryTypeTail

OpenDictionaryTypeTail ::
    >
    , Type >

will address that.

That said, I wish we addressed the "first type must be one of these three things" bit in grammar, not prose. That, though, would cause an irreconcilable FIRST/FIRST conflict, I'm pretty sure. That part is rather annoying. I'm open to ideas for how we can have our LL(1) cake and eat our grammar-enforced sanity too. One obvious way is to make the key type be the second type. Another obvious way is to use different names for the two things... Maybe I'm just overthinking this.

Apart from that, I see the following issues:

Using dictionary here could be somewhat confusing with the totally separate concept of dictionaries, IMO... We may want to come up with a different name.
I'm not sure I follow the "V must be a type allowed for dictionary members." thing: all types are allowed as dictionary members.
We need distinguishability information, overload resolution handling, and union conversion handling for this new type. In practice, it will behave much like "object".
Do we want to allow passing null or undefined to mean "empty open dictionary" the way we do for dictionaries?
I don't know whether the intent here is to be black-box identical in terms of the enumeration to structured clone step 22 substep 3, but this proposed logic is not black-box identical to that, because it calls MOP operations in a different order. It also doesn't call the exact same ones; there's no equivalent of the HasOwnProperty check from structured clone here, because the different ordering, which interleaves the [[GetOwnProperty]] and [[Get]], calls makes it less important to do that. For what it's worth, what Gecko implements for MozMap matches neither of these algorithms; I think we do structured clone step 22 substep 3, but without the extra check in substep 3 subsubstep 1. We also do our conversion to an IDL value right where structured clone would do the StructuredClone recursive call.
"Repeat, for each element [key, value] of entries" is a bit confusing, because each element of entries is an ES Array. This needs to spec how to get the key and value out of the array (probably via Get() calls, not the destructuring that the current language is so suggestive of). Alternately, taking a more structured clone like approach makes this not be an issue, of course.

domenic · 2016-09-30T20:36:03Z

index.bs

+        <a lt="es throw">throw a <emu-val>TypeError</emu-val></a>.
+    1.  Let |result| be a new empty instance of <code>{{dictionary}}<|K|, |V|></code>.
+    1.  Let |entries| be [=EnumerableOwnProperties=](|O|, "key+value").
+    1.  [=ReturnIfAbrupt=](|entries|).


Use ? notation instead of ReturnIfAbrupt.

domenic · 2016-09-30T20:37:39Z

index.bs

+    1.  If [=Type=](|O|) is not <emu-val>Object</emu-val>,
+        <a lt="es throw">throw a <emu-val>TypeError</emu-val></a>.
+    1.  Let |result| be a new empty instance of <code>{{dictionary}}<|K|, |V|></code>.
+    1.  Let |entries| be [=EnumerableOwnProperties=](|O|, "key+value").


You should not use EnumerableOwnProperties here, because EnumerableOwnProperties creates an array. This mixes levels between the abstract (list/records/ES spec devices) and the concrete (Arrays), and also makes it unclear whether in subsequent steps when you do [key, value] what the exact semantics are (e.g. is it impacted by changes to Array.prototype or the iteration protocol).

domenic · 2016-09-30T20:38:15Z

index.bs

+    ECMAScript value|converted=] to an ECMAScript value as follows:
+
+    1.  Let |result| be a new <emu-val>Object</emu-val> instance
+        created as if by the expression <code>{}</code>.


Web IDL may use this phrase elsewhere, but from now on we should be saying "Let result be ! ObjectCreate(%ObjectPrototype%)".

domenic · 2016-09-30T20:39:30Z

index.bs

+        let obj = {__proto__: proto, d: 5, c: 6}
+        Object.defineProperty(obj, "e", {value: 7, enumerable: false});
+        let result = identity(obj);
+        assert(result.a === undefined);


Nit: I like using console.assert in these examples, since it is an actual function that exists in browsers.

domenic · 2016-09-30T20:40:43Z

index.bs

+
+    Dictionary keys and values can be constrained, although keys can only be
+    constrained among the three string types. The following conversions all
+    throw {{TypeError}}s:


Is this true? I thought the conversion behavior was generally to do things like replacing surrogate pairs or returning 0. In particular I am almost certain that converting an object to a long does not throw a TypeError.

Conversion to ByteString will throw if one of the 16-bit code units in the string is larger than 255.

But yes, the other two examples here would not throw: USVString just sticks in a replacement char and converting a random object to an integer type will produce 0.

Good point. I've changed the examples to have a "result" column which shows the coercion.

domenic · 2016-09-30T20:41:25Z

index.bs

+    throw {{TypeError}}s:
+    <table class="data">
+        <thead><th>Value</th><th>Passed to type</th></thead>
+        <tr><td><code>{"😞": 1}</code></td><td><code>{{dictionary}}&lt;ByteString, long></code></td></tr>


Consider never using long in examples, per https://w3ctag.github.io/design-principles/#numeric-types. (long long would be more appropriate in this case.)

I used double since I don't need the integer conversion.

domenic · 2016-09-30T20:44:02Z

IMO we should omit class=algorithm from this PR and, if people think it's desirable, do it in a separate pass all at once.

bzbarsky · 2016-09-30T20:49:35Z

because EnumerableOwnProperties creates an array

If only it did. What it returns is a List of Arrays, when used in "key+value" mode. ;)

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

This avoids calling EnumerableOwnProperties("key+value"), which problematically creates arrays. It's also more similar to StructuredClone().

jyasskin · 2016-10-01T00:25:10Z

I've done everything except the distinguishability information, which I'll work on now.

It looks impossible to enforce that the key is a string in an LL(1) grammar, so I've stayed with the semantic check. It would be possible if we put the key second, but I'm really reluctant to use that confusing syntax. I would be willing to make the key type required.

domenic · 2016-10-01T05:03:15Z

index.bs

+<ol class="algorithm">
+    1.  Let |result| be a new empty instance of <code>{{OpenDictionary}}<|K|, |V|></code>.
+    1.  If [=Type=](|O|) is <emu-val>Undefined</emu-val> or <emu-val>Null</emu-val>,
+        return |result|.


This should throw a TypeError for consistency with closed dictionaries.

This was in response to @bzbarsky's «Do we want to allow passing null or undefined to mean "empty open dictionary" the way we do for dictionaries?», and he's right that closed dictionaries treat null and undefined as empty.

Uh, what are you reading? Can you quote? I see there a very clear step 1 that says "If Type(V) is not Undefined, Null or Object, then throw a TypeError."

Oh, wow, I totally misread the sentence that I quoted. Sorry. This seems good then.

domenic · 2016-10-01T05:04:02Z

index.bs

+    1.  If [=Type=](|O|) is <emu-val>Undefined</emu-val> or <emu-val>Null</emu-val>,
+        return |result|.
+    1.  If [=Type=](|O|) is not <emu-val>Object</emu-val>,
+        <a lt="es throw">throw a <emu-val>TypeError</emu-val></a>.


This check should not be there, for consistency with closed dictionaries.

Again, closed dictionaries do throw a TypeError for non-Object,Null,Undefined arguments: https://heycam.github.io/webidl/#es-to-dictionary

Again, can you quote? There's no such step that I can see; only for RegExp, which we are planning to remove (#148 #145).

As above, my bad; disregard this.

domenic · 2016-10-01T05:06:58Z

index.bs

+        <a lt="es throw">throw a <emu-val>TypeError</emu-val></a>.
+    1.  Let |keys| be [=?=] [=EnumerableOwnProperties=](|O|, "key").
+    1.  Repeat, for each element |key| of |keys| in [=List=] order:
+        1.  If [=!=] [=HasOwnProperty=](|O|, |key|) is <code>true</code>, then:


Interesting. So this comes in to play if enumerating/getting causes side effects that delete the property. I don't think that's great semantics though. I think instead you want to inline the EnumerableOwnProperties algorithm here yourself, instead of separating the enumeration pass from the conversion/Get pass.

I'd like you, @annevk, and @bzbarsky to come to some conclusion about this. So far, @annevk wondered if we should match StructuredClone(), and @bzbarsky said that MozMap is like StructuredClone but omits the HasOwnProperty() check (so, I think we'd include the key in the map but initialize it from undefined). I don't care which we do.

Fair enough. @annevk, @bzbarsky, what do you think of my suggestion? I'm not sure why we do what we do in StrucuredClone, and I suspect legacy constraints.

Maybe @ajklein can tell us? Would rather we make an informed decision here.

I doubt there is much in the way of legacy stuff around structured clone here, honestly.

I think structured clone was created back before there were proxies in ES (but I could totally be wrong about that!). If that were the case, then the [[Get]] calls in that algorithm would have been the only thing that could have changed whether props exist, so it would have made sense to double-check that a previos [[Get]] has not removed the property or something.

In the proxy world, where HasOwnProperty can itself lie and remove the property or whatnot, and where [[GetOwnProperty]] can do likewise, it's not clear to me that there is any sort of sanity that can be provided in the face of a "malicious" input object that just tries to mess with you. So the only question is whether there are sane cases which would benefit from the extra double-checking.

In EnumerableOwnProperties(), the double-checking that exists is just a side-effect of checking for enumerability. That happens to also check that the property is still own, because it uses [[GetOwnProperty]]. But that looks to me like an accidental byproduct of the enumerability check.

Note that structured clone, as specified, is buggy: if one of those [[GetOwnProperty]] calls in step 22.3.2.1.1 returns undefined, what happens?

Also, it's not clear to me whether UAs actually match the structured clone spec. Might be worth checking that...

I guess all of that is to say that I see no obvious problem with removing the HasOwnProperty check in structured clone, with the understanding that this may cause the clone to have own props where the clonee doesn't have any by the time cloning is done... but that's possible now anyway, afaict.

I think what you're missing is that structured clone fails on proxies in step 19.

domenic · 2016-10-01T05:08:31Z

index.bs

+        <tr>
+            <td><code>{"\uD83D": 1}</code></td>
+            <td><code>{{OpenDictionary}}&lt;USVString, double></code></td>
+            <td>[ "\uFFFD" ⇒ 1 ]</td>


It seems you are inconsistent about notation for the mappings; here you use an arrow, whereas above you use "Repeat, for each mapping (key, value) in D". Both seem reasonable, but it would be good to pick one and maybe mention it in the section that introduces the concept of mappings.

Yeah. I don't want to make WebIDL's users type a non-ascii character in order to iterate over a map, so (key, value) is better for that. I can change to that here too.

tobie · 2016-10-03T09:24:54Z

@jyasskin wrote:

It looks impossible to enforce that the key is a string in an LL(1) grammar, so I've stayed with the semantic check. It would be possible if we put the key second, but I'm really reluctant to use that confusing syntax. I would be willing to make the key type required.

So I know just enough about grammars to be able to read them and defer to those more knowledgeable on the topic (pointers to good resources are welcomed, btw). I concur that putting the key second is a really bad idea and would suggest making both keys required. It's slightly more verbose, but also much clearer. I imagine we'd go for something like this?

OpenDictionaryType ::
    dictionary < OpenDictionaryKeyType , Type >

OpenDictionaryKeyType ::
    "DOMString"
    "USVString"
    "ByteString"

bzbarsky · 2016-10-14T17:30:35Z

If we interleave the Get()s we should interleave the to-IDL-value conversions too so we don't have to build up a temporary list of values. Imo.

jyasskin · 2016-10-14T18:53:47Z

index.bs

+        1.  If |desc| is not <emu-val>undefined</emu-val>
+            and |desc|.[=[[Enumerable]]=] is <emu-val>true</emu-val>:
+            1.  Let |typedKey| be |key| [=converted to an IDL value=] of type |K|.
+            1.  Let |value| be [=?=] [=Get=](|O|, |key|).


@domenic Done. Note that it's a little weird to call Get() when we already have the descriptor, but that's what Object.assign() does so oh well.

domenic

Mostly LGTM, a few nits and suggestions

domenic · 2016-10-14T19:46:24Z

index.bs

+
+<ol class="algorithm">
+    1.  Let |result| be a new empty instance of <code>{{record}}&lt;|K|, |V|></code>.
+    1.  If [=Type=](|O|) is <emu-val>Undefined</emu-val> or <emu-val>Null</emu-val>,


Nit: types (Undefined, Null, and Object) are not emu-vals. That is reserved for language values, not spec values.

Done. Is there documentation for that?

https://bterlson.github.io/ecmarkup/#editorial-conventions I guess, although that's not the most obvious place to look given that we're basically only using emu-val.

domenic · 2016-10-14T19:48:37Z

index.bs

+            1.  If |typedKey| is already a key in |result|, set its value to |typedValue|.
+
+                Note: This can happen when |O| is a proxy object.
+            1.  Otherwise, append to |result| a mapping from |typedKey| to |typedValue|.


Link mapping? And use (|typedKey|, |typedValue|) notation?

domenic · 2016-10-14T19:50:32Z

index.bs

+</ol>
+
+<div class="example" id="example-es-record">
+    Passing the ECMAScript value <code>{b: 3, a: 4}</code> to a


domenic · 2016-10-14T19:51:16Z

index.bs

+<div class="example" id="example-es-record">
+    Passing the ECMAScript value <code>{b: 3, a: 4}</code> to a
+    <code>{{record}}&lt;DOMString, double></code> argument
+    would result in the IDL value <code>[ ("b", 3), ("a", 4) ]</code>.


I don't know about this new array-ish notation. I'd instead say something like "a record containing the two mappings ("b", 3) and ("a", 4), in that order." Hmm, I guess it makes an appearance later in the table too, where it's more necessary for space reasons... not sure what to do. At least, remove the <code> from this one, IMO.

I think this also contradicts the statement "There is no way to represent a constant record value in IDL."

I think

There is no way to represent a constant record value in IDL.

means that we don't have syntax for it in the WebIDL grammar. The phrase,

a record containing the two mappings ("b", 3) and ("a", 4), in that order.

would still "represent a constant record value", but I'd like to have a more concise way to do it.

I'm still hesitant about using notation that's reminiscent of JS arrays, and is not defined anywhere. Maybe use some exotic type of bracket (such as the french double quotes that ES uses), and define it in the same place you define the mapping notation?

Perfect, thanks!

domenic · 2016-10-14T19:53:30Z

index.bs

@@ -7695,6 +7837,9 @@ represented by ECMAScript values that correspond to the union’s
        1.  If |types| includes a [=dictionary type=], then return the
            result of [=converted to an IDL value|converting=]
            |V| to that dictionary type.
+        1.  If |types| includes a [=record type=], then return the
+            result of [=converted to an IDL value|converting=]
+            |V| to that dictionary type.


s/dictionary/record

Whoops, done.

domenic · 2016-10-14T19:53:59Z

index.bs

+        return |result|.
+    1.  If [=Type=](|O|) is not <emu-val>Object</emu-val>,
+        <a lt="es throw">throw a <emu-val>TypeError</emu-val></a>.
+    1.  Let |keys| be [=?=] |O|.[=[[OwnPropertyKeys]]=]().


IMO the links for the internal methods and [[enumerable]] are not good to add here. If we want to do that more generally, we can, but we shouldn't do it just in this section.

jyasskin

Thanks!

jyasskin · 2016-10-14T19:59:37Z

index.bs

+        return |result|.
+    1.  If [=Type=](|O|) is not <emu-val>Object</emu-val>,
+        <a lt="es throw">throw a <emu-val>TypeError</emu-val></a>.
+    1.  Let |keys| be [=?=] |O|.[=[[OwnPropertyKeys]]=]().


jyasskin · 2016-10-14T20:00:42Z

index.bs

+            1.  If |typedKey| is already a key in |result|, set its value to |typedValue|.
+
+                Note: This can happen when |O| is a proxy object.
+            1.  Otherwise, append to |result| a mapping from |typedKey| to |typedValue|.


jyasskin · 2016-10-14T20:01:02Z

index.bs

+</ol>
+
+<div class="example" id="example-es-record">
+    Passing the ECMAScript value <code>{b: 3, a: 4}</code> to a


jyasskin · 2016-10-14T20:04:42Z

index.bs

+<div class="example" id="example-es-record">
+    Passing the ECMAScript value <code>{b: 3, a: 4}</code> to a
+    <code>{{record}}&lt;DOMString, double></code> argument
+    would result in the IDL value <code>[ ("b", 3), ("a", 4) ]</code>.


I think

There is no way to represent a constant record value in IDL.

means that we don't have syntax for it in the WebIDL grammar. The phrase,

a record containing the two mappings ("b", 3) and ("a", 4), in that order.

would still "represent a constant record value", but I'd like to have a more concise way to do it.

jyasskin · 2016-10-14T20:05:30Z

index.bs

@@ -7695,6 +7837,9 @@ represented by ECMAScript values that correspond to the union’s
        1.  If |types| includes a [=dictionary type=], then return the
            result of [=converted to an IDL value|converting=]
            |V| to that dictionary type.
+        1.  If |types| includes a [=record type=], then return the
+            result of [=converted to an IDL value|converting=]
+            |V| to that dictionary type.


Whoops, done.

bzbarsky · 2016-10-17T16:06:20Z

@tobie, @jyasskin, @domenic Are we sure we want the "is already present" behavior as checked in? That seems a bit annoying to implement in terms of performance, and it's not really clear to me why we're doing it at all.

Fix distinguishable algorithm. Closes whatwg#190. Fix record handling in various algorithms. Closes whatwg#191, closes whatwg#189

Fix distinguishable algorithm. Closes whatwg#190. Fix record handling in various algorithms. Closes whatwg#191, closes whatwg#189.

Fix distinguishable algorithm. Closes #190. Fix record handling in various algorithms. Closes #191, closes #189.

jyasskin · 2016-10-18T17:50:25Z

@bzbarsky I don't see "is already present" in the spec. Do you mean the "If typedKey is already a key in result," wording? That's the same operation as in Map.prototype.set, which I believe we implement efficiently. I do think we want to avoid the possibility of a record winding up with a duplicate key: it can only happen with a proxy object input, and spec authors are unlikely to consider it and handle it well.

bzbarsky · 2016-10-18T18:00:43Z

Do you mean the "If typedKey is already a key in result," wording?

Yes.

That's the same operation as in Map.prototype.set, which I believe we implement efficiently.

It's possible to do. It just requires some performance/memory/complexity tradeoffs, which it's not clear to me are valuable here.

I do think we want to avoid the possibility of a record winding up with a duplicate key

I guess the question is whether it's better to have implementation complexity/overhead to handle the rare proxy case or to have specification complexity instead.

https://dev.w3.org/html5/html-design-principles/#priority-of-constituencies would normally err on the side of specification complexity, but this is an odd case where we are likely to have more specifiers affected than implementors, so maybe this is the right tradeoff...

In any case, I just wanted to make sure we are explicitly and deliberately making this choice and understand that it's likely to cause implementation delays, in general.

jyasskin · 2016-10-18T18:10:12Z

We could also throw a TypeError in the case of a duplicated key, which would allow the implementation to just keep a set of used keys, instead of needing to be able to find the value associated with a previously-used key.

bzbarsky · 2016-10-18T18:17:03Z

That makes things a bit simpler, but not really that much simpler. You still need some sort of dual-purpose data structure (O(1) lookup and fixed-order iteration).

annevk · 2016-10-19T05:24:43Z

The specification complexity would be making that duplicate key check and then throwing? Seems better handled by IDL, or would specifications handle it in other ways?

bzbarsky · 2016-10-19T12:58:42Z

The specification complexity would be making that duplicate key check and then throwing?

Or whatever they want to do in the duplicate case. @jyasskin is probably right that spec authors won't even realize they should handle it, so it probably does make sense to handle in IDL. It just makes me a bit sad that ES proxies don't enforce this themselves per spec. :(

domenic · 2016-10-19T14:09:47Z

It looks like there is talk of proxies enforcing that in tc39/ecma262#461. I am not sure whether there was consensus to change though...

jyasskin force-pushed the open-dictionaries branch from c387f70 to 9392a5d Compare September 30, 2016 01:25

annevk added a commit that referenced this pull request Sep 30, 2016

Remove "initializing objects from iterables"

eed5467

This feature was introduced by #13, but the main thing we actually needed for Headers et al was open dictionaries (see #180). As such this feature has not seen any use.

annevk mentioned this pull request Sep 30, 2016

Remove "initializing objects from iterables" #181

Merged

jyasskin commented Sep 30, 2016

View reviewed changes

tobie reviewed Sep 30, 2016

View reviewed changes

jyasskin force-pushed the open-dictionaries branch from 50d5fa2 to 12721f5 Compare September 30, 2016 17:56

domenic reviewed Sep 30, 2016

View reviewed changes

jyasskin and others added 5 commits September 30, 2016 16:38

Specify open dictionaries.

2e084f4

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

Add the 1-arg dictionary<> form to the grammar.

2008d7f

Make the grammar LL(1).

2b5f2a8

Rename dictionary<> to OpenDictionary<>.

3dc8ca9

Remove constraint on OpenDictionary<> value type.

1a8ae76

jyasskin force-pushed the open-dictionaries branch from 12721f5 to 1a8ae76 Compare September 30, 2016 23:40

jyasskin added 6 commits September 30, 2016 16:44

Undo use of <div algorithm>.

05252bf

Interleave type checks with property retrieval.

747ba1e

This avoids calling EnumerableOwnProperties("key+value"), which problematically creates arrays. It's also more similar to StructuredClone().

Convert null and undefined to empty OpenDictionary<>s.

6646a17

Use ObjectCreate instead of {}.

7c5c25a

Use console.assert() instead of assert().

756f55d

Improve examples.

399fc10

domenic reviewed Oct 1, 2016

View reviewed changes

Interleave enumerability checks with Gets and type conversions.

fe44f9c

jyasskin commented Oct 14, 2016

View reviewed changes

Fix a couple <code>s and unescaped <s.

665d408

domenic reviewed Oct 14, 2016

View reviewed changes

Woot! Down to nits!

9e22b41

jyasskin commented Oct 14, 2016

View reviewed changes

Use «» to represent a record's sequence of mappings.

20c46cc

domenic approved these changes Oct 14, 2016

View reviewed changes

tobie merged commit 1814384 into whatwg:gh-pages Oct 17, 2016

jyasskin deleted the open-dictionaries branch October 17, 2016 15:45

This was referenced Oct 17, 2016

Distinguishability of nullable types and dictionaries seems broken #190

Closed

record inside union is not handled correctly in overload resolution algorithm #189

Closed

record inside union is not handled correctly in es-to-union conversion #191

Closed

tobie added a commit to tobie/webidl that referenced this pull request Oct 17, 2016

Various follow-up fixes to whatwg#180.

90b4b11

Fix distinguishable algorithm. Closes whatwg#190. Fix record handling in various algorithms. Closes whatwg#191, closes whatwg#189

tobie added a commit to tobie/webidl that referenced this pull request Oct 17, 2016

Various follow-up fixes to whatwg#180.

2416a2b

Fix distinguishable algorithm. Closes whatwg#190. Fix record handling in various algorithms. Closes whatwg#191, closes whatwg#189

tobie added a commit to tobie/webidl that referenced this pull request Oct 17, 2016

Various follow-up fixes to whatwg#180.

7448c6c

Fix distinguishable algorithm. Closes whatwg#190. Fix record handling in various algorithms. Closes whatwg#191, closes whatwg#189.

tobie added a commit that referenced this pull request Oct 18, 2016

Various follow-up fixes to #180. (#192)

40d03aa

Fix distinguishable algorithm. Closes #190. Fix record handling in various algorithms. Closes #191, closes #189.

foolip mentioned this pull request Nov 9, 2016

Should AlgorithmIdentifier be (Algorithm or DOMString)? w3c/webcrypto#161

Closed

jyasskin mentioned this pull request Feb 3, 2017

Do records (record<>s) purposefully throw on any object with an enumerable Symbol-named property? #294

Open

mkovatsc mentioned this pull request Apr 10, 2018

Clear description of the issue "using WebIDL to describe maplike access of JSON-LD documents with @ fields" w3c/wot-scripting-api#108

Closed

shvaikalesh mentioned this pull request Sep 21, 2020

Update obsolete note on duplicate Proxy [[OwnPropertyKeys]] entries #925

Merged

Specify open dictionaries. #180

Specify open dictionaries. #180

Conversation

jyasskin commented Sep 30, 2016 • edited by tobie Loading

annevk commented Sep 30, 2016

annevk commented Sep 30, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobie commented Sep 30, 2016

jyasskin commented Sep 30, 2016

tobie Sep 30, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bzbarsky commented Sep 30, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic commented Sep 30, 2016

bzbarsky commented Sep 30, 2016

jyasskin commented Oct 1, 2016

domenic Oct 1, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobie commented Oct 3, 2016 • edited Loading

bzbarsky commented Oct 14, 2016

Choose a reason for hiding this comment

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jyasskin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bzbarsky commented Oct 17, 2016

jyasskin commented Oct 18, 2016

bzbarsky commented Oct 18, 2016

jyasskin commented Sep 30, 2016 •

edited by tobie

Loading

tobie Sep 30, 2016 •

edited

Loading

domenic Oct 1, 2016 •

edited

Loading

tobie commented Oct 3, 2016 •

edited

Loading