On Tue, Nov 15, 2011 at 9:09 AM, Joshua Bell <jsb...@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.prototypeI 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 We could say that the clone created when storing in the database is created in a separate global scope. / Jonas
