- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 15 Nov 2011 16:32:39 -0800
- To: Joshua Bell <jsbell@chromium.org>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>
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. / Jonas
Received on Wednesday, 16 November 2011 00:33:48 UTC