Re: [indexeddb] Keypath attribute lookup question

On Tue, Nov 15, 2011 at 1:33 PM, Jonas Sicking <jonas@sicking.cc> wrote:

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


In terms of the behavior we care about they're the same.

In terms of finely specifying how we evaluate keypaths: String values and
String objects are different beasts, e.g.  "length" in [1,2,3] --> true,
"length" in "abc" --> TypeError, "length" in new String("abc") --> true. It
turns out that "abc".length is short for Object("abc").length which in turn
is (new String("abc")).length which is really (new
String("abc"))["length"]. So putting on the pedantic hat, "string" doesn't
have any properties, it just behaves like it does c/o the fine grained
rules of the [] operation in ECMAScript.

Wheee.