- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 31 May 2011 10:34:56 -0700
- To: Jonas Sicking <jonas@sicking.cc>, Israel Hilerio <israelh@microsoft.com>, public-webapps@w3.org
On Fri, May 27, 2011 at 3:38 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> Israel Hilerio:
>> > For the optional parameters variable that is expected by the
>> > IDBDatabase.createObjectStore function, would it be possible to constrain
>> > the variable to have the keyPath and autoIncrement attributes as part of its
>> > instance members and not as part of its inheritance hierarchy?
>
> Jonas Sicking:
>> For example we asked that it should not be allowed to implement the
>> properties using getters as to avoid having to worry about javascript
>> running from inside the createObjectStore implementation, however the
>> feedback we got was unanimously strongly opposed that.
>
> One advantage of looking only at own properties is that it would make it
> easier if for example you were defining a dictionary type that had
> members named "prototype", "toString", etc.
>
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12248
>
> There were two options I was considering in the bug. The first was to
> test whether the object the property like `"keyPath" in optionsObject`:
>
> keyPathSpecified = optionsObject.[[HasProperty]]("keyPath")
> if keyPathSpecified then
> keyPath = ToString(optionsObject.[[Get]]("keyPath"))
> else
> keyPath = <default value for keyPath>
> end if
>
> The second is to unconditionally get the property and compare it against
> undefined:
>
> keyPath = optionsObject.[[Get]]("keyPath")
> if keyPath is undefined then
> keyPath = <default value for keyPath>
> else
> keyPath = ToString(optionsObject.[[Get]]("keyPath"))
> end if
>
> Both of these would still find "toString" from the prototype, though.
> You could easily define it such that you do only look up own properties,
> but as Jonas says some people may think of that as less “JavaScripty”
> than the other options.
At least in the indexedDB case we need to enumerate the object anyway
since we want to throw if it contains any properties that we don't
understand. This is for forwards compatible reasons.
Hence we automatically limit ourselves to enumerable properties, so
toString wouldn't be a problem.
/ Jonas
Received on Tuesday, 31 May 2011 17:36:00 UTC