Re: [heycam/webidl] Specify open dictionaries. (#180)

bzbarsky commented on this pull request.



> +IDL {{OpenDictionary}}<|K|, |V|> values are represented by
+ECMAScript <emu-val>Object</emu-val> values.
+
+<p id="es-to-open-dictionary">
+    An ECMAScript value |O| is [=converted to an IDL value|converted=] to an IDL <code>{{OpenDictionary}}<|K|, |V|></code> value as follows:
+</p>
+
+<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|.
+    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 [=?=] [=EnumerableOwnProperties=](|O|, "key").
+    1.  Repeat, for each element |key| of |keys| in [=List=] order:
+        1.  If [=!=] [=HasOwnProperty=](|O|, |key|) is <code>true</code>, then:

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/180