Re: [indexeddb] Keypath attribute lookup question

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