Re: [indexeddb] Keypath attribute lookup question

On Tue, Nov 15, 2011 at 12:05 PM, Joshua Bell <jsbell@chromium.org> wrote:
> On Tue, Nov 15, 2011 at 11:42 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Tue, Nov 15, 2011 at 9:09 AM, Joshua Bell <jsbell@chromium.org> wrote:
>> >> I do however think that we should simply state that getting the index
>> >> values will use the normal method for looking up properties on JS
>> >> objects. This includes walking the prototype chain. Practically
>> >> speaking this only makes a difference on host objects like Files and
>> >> ArrayBuffers since plain JS objects loose their prototype during
>> >> structured clones.
>> >
>> > Since I lurk on es-discuss, I have to nitpick that this leaves spec
>> > ambiguity around Object.prototype and async operations. The HTML5 spec
>> > sayeth re: structured cloning of objects: "Let output be a newly
>> > constructed
>> > empty Object object" - that implies (to me) that the clone's prototype
>> > is
>> > Object.prototype.
>> > Here's where the ambiguity comes in - assume async API usage:
>> > my_store.createIndex("some index", "foo");
>> > ...
>> > Object.prototype.foo = 1;
>> > my_store.put(new Object);
>> > Object.prototype.foo = 2;
>> > // what indexkey was used?
>> > One possibility would be to modify the structured clone algorithm (!) to
>> > mandate that the Object has no prototype (i.e. what you get from
>> > Object.create(null)) but that would probably surprise developers since
>> > the
>> > resulting objects wouldn't have toString() and friends. Scoped to just
>> > IDB
>> > we could explicitly exclude Object.prototype
>>
>> I don't think we want to say that structured clones create objects
>> without a prototype since when you read objects out of the database we
>> use structured clone, and there we definitely want to create objects
>> which use the page's normal
>> Object.prototype/Array.prototype/File.prototype
>
> Totally agree, that suggestion was a true straw-man intended to be burned.
>
>>
>> We could say that the clone created when storing in the database is
>> created in a separate global scope.
>
> Very nice - I think that captures the semantics we want (namely, that script
> should not be able to distinguish whether implementations are operating on a
> serialized form or a "live" object.)
> This would imply that you can index on the special "length" property of
> Arrays, which seems useful. How about "length" of String instances (which is
> spec'd slightly differently)? I think those are the only two relevant
> special properties.

Good point. How is "string".length different from [].length? (Other
than that strings are immutable and so never change their length).

/ Jonas

Received on Tuesday, 15 November 2011 21:35:03 UTC