Re: [IndexedDB] Any particular reason built-in properties are not indexable?

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