RE: [indexedDB] OptionalParameter question on IDBDatabase.createObjectStore
On Fri, May 27, 2011 at 2011 12:43 PM, Jonas Sicking wrote: -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Friday, May 27, 2011 12:43 PM To: Israel Hilerio Cc: public-webapps@w3.org Subject: Re: [indexedDB] OptionalParameter question on IDBDatabase.createObjectStore On Fri, May 27, 2011 at 10:27 AM, Israel Hilerio isra...@microsoft.com wrote: 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? I think that would not ring well with the ECMAScript people in TC39. 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. / Jonas Makes sense! What about lifting up the constraint around validating that the property bag have _only_ the specified properties and nothing else? Thus, removing the following exception: Exception -- NON_TRANSIENT_ERR optionalParameters has attributes other than keyPath and autoIncrement. The complexity increases the more things we have to validate against. Israel
Re: [indexedDB] OptionalParameter question on IDBDatabase.createObjectStore
On Fri, May 27, 2011 at 3:38 PM, Cameron McCormack c...@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
Re: [indexedDB] OptionalParameter question on IDBDatabase.createObjectStore
Jonas Sicking:
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.
The way I’ve specified dictionaries, there is no way to know what other
properties might exist on the JS object. If you defined
dictionary ObjectStoreCreationOptions {
DOMString keyPath = ;
boolean autoIncrement = false;
};
then the (IDL level) dictionary value will only ever have a keyPath and
an autoIncrement entry.
I could add a flag to the dictionary that indicates whether “unexpected”
properties were on the (language level) object, so that IndexedDB can
act upon it by throwing an exception. I’m just not sure that this is a
common usage pattern of options objects in JS. To me, the simplest use
of the properties on the options object would be:
function createObjectStore(name, optionalParameters) {
optionalParameters = optionalParameters || { };
var keyPath = optionalParameters.keyPath || ;
var autoIncrement = optionalParameters.autoIncrement;
...
}
Doing:
function createObjectStore(name, optionalParameters) {
optionalParameters = optionalParameters || { };
var keyPath = optionalParameters.keyPath || ;
var autoIncrement = optionalParameters.autoIncrement;
for (var key in optionalParameters) {
if (key != keyPath key != autoIncrement) {
throw ...;
}
}
...
}
feels kind of unnecessary. Are you thinking that authors will feature
test for new options by doing something like the following?
try {
createObjectStore(test, { newOption: 123 });
} catch (e) {
if (e.code == IDBDatabaseException.NON_TRANSIENT_ERR) {
// fall back to something else that does use newOption
}
}
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [indexedDB] OptionalParameter question on IDBDatabase.createObjectStore
On Tue, May 31, 2011 at 3:09 PM, Cameron McCormack c...@mcc.id.au wrote:
Jonas Sicking:
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.
The way I’ve specified dictionaries, there is no way to know what other
properties might exist on the JS object. If you defined
dictionary ObjectStoreCreationOptions {
DOMString keyPath = ;
boolean autoIncrement = false;
};
then the (IDL level) dictionary value will only ever have a keyPath and
an autoIncrement entry.
I could add a flag to the dictionary that indicates whether “unexpected”
properties were on the (language level) object, so that IndexedDB can
act upon it by throwing an exception. I’m just not sure that this is a
common usage pattern of options objects in JS. To me, the simplest use
of the properties on the options object would be:
function createObjectStore(name, optionalParameters) {
optionalParameters = optionalParameters || { };
var keyPath = optionalParameters.keyPath || ;
var autoIncrement = optionalParameters.autoIncrement;
...
}
Doing:
function createObjectStore(name, optionalParameters) {
optionalParameters = optionalParameters || { };
var keyPath = optionalParameters.keyPath || ;
var autoIncrement = optionalParameters.autoIncrement;
for (var key in optionalParameters) {
if (key != keyPath key != autoIncrement) {
throw ...;
}
}
...
}
feels kind of unnecessary.
It's certainly harder to implement, but it does IMHO result in a
better API for webpages to use which is more important.
Are you thinking that authors will feature
test for new options by doing something like the following?
try {
createObjectStore(test, { newOption: 123 });
} catch (e) {
if (e.code == IDBDatabaseException.NON_TRANSIENT_ERR) {
// fall back to something else that does use newOption
}
}
Yes, that is one option. Another could be something like:
if (objectStore.spiffyNewIndexes) {
objectStore.createIndex(test, { spiffy: true });
}
else {
objectStore.createIndex(test, { keyPath: foo });
}
In any case it's better to throw than silently ignore unknown properties IMHO.
/ Jonas
[indexedDB] OptionalParameter question on IDBDatabase.createObjectStore
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? Israel
Re: [indexedDB] OptionalParameter question on IDBDatabase.createObjectStore
On Fri, May 27, 2011 at 10:27 AM, Israel Hilerio isra...@microsoft.com wrote: 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? I think that would not ring well with the ECMAScript people in TC39. 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. / Jonas
Re: [indexedDB] OptionalParameter question on IDBDatabase.createObjectStore
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/
