- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 15 Nov 2011 11:42:33 -0800
- To: Joshua Bell <jsbell@chromium.org>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>
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
We could say that the clone created when storing in the database is
created in a separate global scope.
/ Jonas
Received on Tuesday, 15 November 2011 19:43:35 UTC