- From: Pablo Castro <Pablo.Castro@microsoft.com>
- Date: Tue, 22 Mar 2011 22:30:30 +0000
- To: Jonas Sicking <jonas@sicking.cc>
- CC: public-webapps WG <public-webapps@w3.org>
-----Original Message----- From: Jonas Sicking [mailto:jonas@sicking.cc] Sent: Monday, March 21, 2011 2:54 PM >> 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. I'm fine not supporting it, I just wanted to bring it up because it came up here and wanted to make sure we made an explicit call. I'd rather not one-off Array.length, so it seems it would be best to just not do it across the board. Thanks -pablo
Received on Tuesday, 22 March 2011 22:31:06 UTC