- From: Cameron McCormack <cam@mcc.id.au>
- Date: Sat, 28 May 2011 10:38:57 +1200
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Israel Hilerio <israelh@microsoft.com>, public-webapps@w3.org
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.
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Friday, 27 May 2011 22:39:31 UTC