- 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>
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 UTC