-----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 -pabloReceived on Tuesday, 22 March 2011 22:31:06 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:17 UTC