Re: [indexeddb] Keypath attribute lookup question

On Tue, Nov 15, 2011 at 2:20 PM, Joshua Bell <jsbell@chromium.org> wrote:
> 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.

Hmm.. good point. Looking at the documentation for the built-in types,
there are unfortunately also a host of constant properties on implicit
Number objects. But I'm not convinced that you should be able to index
on "somenumberProp.NEGATIVE_INFINITY".

How about we say that key-paths can only access properties explicitly
copied by the structured clone algorithm plus the following:

Blob.size
Blob.type
File.name
File.lastModifiedDate
Array.length
String.length

/ Jonas

Received on Tuesday, 15 November 2011 22:40:15 UTC