W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

RE: [indexeddb] Keypath attribute lookup question

From: Israel Hilerio <israelh@microsoft.com>
Date: Wed, 16 Nov 2011 00:41:04 +0000
To: "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>, "jsbell@chromium.org" <jsbell@chromium.org>
CC: "public-webapps@w3.org" <public-webapps@w3.org>, Jim Wordelman <jaword@microsoft.com>, Travis Leithead <travis.leithead@microsoft.com>, Gaurav Seth <Seth.Gaurav@microsoft.com>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E3F54FB02@TK5EX14MBXC117.redmond.corp.microsoft.com>
On Tuesday, November 15, 2011 4:33 PM, Jonas Sicking wrote:
> On Tue, Nov 15, 2011 at 3:14 PM, Joshua Bell <jsbell@chromium.org> wrote:
> > On Tue, Nov 15, 2011 at 2:39 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>
> >> 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".
> >
> > Those are on the Number object itself, not Number.prototype and hence
> > not inherited by instances of Number, so you can't do
> > (1).NEGATIVE_INFINITY. You can't structured-clone Number itself (it's
> > a function); you probably could structured-clone Math, but the
> > behavior would be predictable (either the properties would clone or
> > they wouldn't, but the resulting object would be distinct from the
> > global Math object itself). It's just the sections "Properties of XXX Instances"
> and "Properties of the XXX Prototype Object"
> > that we need to worry about. The others are functions - while these
> > would exist in the theoretical new global context, they aren't valid
> > keys. So I think the Array and String "length" properties are the only
> > interesting cases.
> 
> Good point, i missed the fact that the properties are on Number and not on
> Number. So even defining it as a plan property lookup would give the same
> behavior as below.
> 
> >> 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
> >
> > That would certainly make conformance testing a lot easier. +1 from me.
> 
> Sounds good.

This is the outcome we were hoping for.  Do we need to add anything to the IDB spec to capture this behavior or is already covered (perhaps a note)?

Israel

> 
> / Jonas
> 
Received on Wednesday, 16 November 2011 00:41:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT