Re: [indexeddb] Keypath attribute lookup question

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.