- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 21 Mar 2011 14:54:25 -0700
- To: Pablo Castro <Pablo.Castro@microsoft.com>
- Cc: public-webapps WG <public-webapps@w3.org>
On Mon, Mar 21, 2011 at 11:51 AM, Pablo Castro <Pablo.Castro@microsoft.com> wrote: > The spec today requires that properties key paths point at need to be > enumerated (see 3.1.2 “Object Store”). Any particular reason for that? It > would be reasonable to allow an index on say the “length” property of a > string. Perhaps we’re opening the door for too much, so I wanted to double > check so we make an explicit call one way or the other. Thoughts? The structured clone algorithm only copies enumerable properties, given how we currently do indexes it would be sort of strange if you could add an index on a property that isn't stored. This is generally not a problem though. Before ES5 there wasn't even a way to create non-enumerated properties. They only appeared on host objects which you can't structured-clone anyway. One exception to this is Array.length which you mention. While that property isn't copied by the structured-clone algorithm, it's recreated by it since a new array object is created which contains a length property computed according to the same rules. We could special-case the array.length property in the keyPath evaluation algorithm. We might want to do the same for other host-object properties such as Blob.size and Blob.type since they aren't actually structured-cloned since they live on the prototype chain rather than the objects themselves. / Jonas
Received on Monday, 21 March 2011 21:55:30 UTC