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

-----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