Re: [indexeddb] Keypath attribute lookup question

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.


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