RE: [indexeddb] Handling negative parameters for the advance method
Hmm.. Yeah, I suspect that is the better behavior here. We should probably also throw if the number is 0. / Jonas If a developer specifies zero as a value, we could throw an IDBDatabaseException with a value of NON_TRANSIENT_ERR. What about doing the same for negative values? Israel For cursor.advance() in sync async, I changed count parameter type to long and added NON_TRANSIENT_ERR: ExceptionDescription IDBDatabaseExceptionNON_TRANSIENT_ERR The value passed into the count parameter was zero or a negative number. Thanks, Eliot
RE: [indexeddb] Handling negative parameters for the advance method
On Sunday, August 14, 2011 4:09 PM, Aryeh Gregor wrote: On Fri, Aug 12, 2011 at 6:16 PM, Jonas Sicking jo...@sicking.cc wrote: Yup. Though I think WebIDL will take care of the handling for when the author specifies a negative value. I.e. WebIDL will specify what exception to throw, so we don't need to. Similar to how WebIDL specifies what exception to throw if the author specifies too few parameters, or parameters of the wrong type. It doesn't throw an exception -- the input is wrapped. It basically calls the ToUInt32 algorithm from ECMAScript: http://dev.w3.org/2006/webapi/WebIDL/#es-unsigned-long This behavior is apparently needed for compat, or so I was told when I complained that it's ridiculous to treat JS longs like C. It does have the one (arguable) advantage that authors can use -1 for maximum allowed value. But anyway, yes: if your IDL says unsigned, then your algorithm can't define behavior for what happens when the input is negative, because WebIDL will ensure the algorithm never sees a value outside the allowed range. If you want special behavior for negative values, you have to use a regular long. I like Areyh's suggestion. What if we were to keep the parameter as a long and specify in the spec that zero and negative values will not advance the cursor in any direction. We could add something like this: If the count value is less than or equal to zero the iteration will not take place. After thinking about this some more, I like this better than having the unexpected side effects of passing a negative number to a unsigned long parameter. Jonas, what do you think? Israel
Re: [indexeddb] Handling negative parameters for the advance method
On Mon, Aug 15, 2011 at 10:29 AM, Israel Hilerio isra...@microsoft.com wrote: On Sunday, August 14, 2011 4:09 PM, Aryeh Gregor wrote: On Fri, Aug 12, 2011 at 6:16 PM, Jonas Sicking jo...@sicking.cc wrote: Yup. Though I think WebIDL will take care of the handling for when the author specifies a negative value. I.e. WebIDL will specify what exception to throw, so we don't need to. Similar to how WebIDL specifies what exception to throw if the author specifies too few parameters, or parameters of the wrong type. It doesn't throw an exception -- the input is wrapped. It basically calls the ToUInt32 algorithm from ECMAScript: http://dev.w3.org/2006/webapi/WebIDL/#es-unsigned-long This behavior is apparently needed for compat, or so I was told when I complained that it's ridiculous to treat JS longs like C. It does have the one (arguable) advantage that authors can use -1 for maximum allowed value. But anyway, yes: if your IDL says unsigned, then your algorithm can't define behavior for what happens when the input is negative, because WebIDL will ensure the algorithm never sees a value outside the allowed range. If you want special behavior for negative values, you have to use a regular long. I like Areyh's suggestion. What if we were to keep the parameter as a long and specify in the spec that zero and negative values will not advance the cursor in any direction. We could add something like this: If the count value is less than or equal to zero the iteration will not take place. After thinking about this some more, I like this better than having the unexpected side effects of passing a negative number to a unsigned long parameter. Jonas, what do you think? Hmm.. Yeah, I suspect that is the better behavior here. We should probably also throw if the number is 0. / Jonas
RE: [indexeddb] Handling negative parameters for the advance method
On Monday, August 15, 2011 2:22 PM, Jonas Sicking wrote: On Mon, Aug 15, 2011 at 10:29 AM, Israel Hilerio isra...@microsoft.com wrote: On Sunday, August 14, 2011 4:09 PM, Aryeh Gregor wrote: On Fri, Aug 12, 2011 at 6:16 PM, Jonas Sicking jo...@sicking.cc wrote: Yup. Though I think WebIDL will take care of the handling for when the author specifies a negative value. I.e. WebIDL will specify what exception to throw, so we don't need to. Similar to how WebIDL specifies what exception to throw if the author specifies too few parameters, or parameters of the wrong type. It doesn't throw an exception -- the input is wrapped. It basically calls the ToUInt32 algorithm from ECMAScript: http://dev.w3.org/2006/webapi/WebIDL/#es-unsigned-long This behavior is apparently needed for compat, or so I was told when I complained that it's ridiculous to treat JS longs like C. It does have the one (arguable) advantage that authors can use -1 for maximum allowed value. But anyway, yes: if your IDL says unsigned, then your algorithm can't define behavior for what happens when the input is negative, because WebIDL will ensure the algorithm never sees a value outside the allowed range. If you want special behavior for negative values, you have to use a regular long. I like Areyh's suggestion. What if we were to keep the parameter as a long and specify in the spec that zero and negative values will not advance the cursor in any direction. We could add something like this: If the count value is less than or equal to zero the iteration will not take place. After thinking about this some more, I like this better than having the unexpected side effects of passing a negative number to a unsigned long parameter. Jonas, what do you think? Hmm.. Yeah, I suspect that is the better behavior here. We should probably also throw if the number is 0. / Jonas If a developer specifies zero as a value, we could throw an IDBDatabaseException with a value of NON_TRANSIENT_ERR. What about doing the same for negative values? Israel
RE: [indexeddb] Handling negative parameters for the advance method
On Friday, August 12, 2011 3:17 PM, Jonas Sicking wrote: On Fri, Aug 12, 2011 at 2:34 PM, Israel Hilerio isra...@microsoft.com wrote: Since advance is intended to always move the cursor forward, it seems we want to only support positive parameter values. Therefore, I would suggest we change its signature to: void advance (in unsigned int count); If a developer specifies a negative number for it, we could throw an IDBDatabaseException with a value of NON_TRANSIENT_ERR. A value of zero will do nothing. I also noticed that the webIDL spec doesn't define int or unsigned int. It seems we should be using long (for int) and unsigned long (unsigned int). Do you agree? Yup. Though I think WebIDL will take care of the handling for when the author specifies a negative value. I.e. WebIDL will specify what exception to throw, so we don't need to. Similar to how WebIDL specifies what exception to throw if the author specifies too few parameters, or parameters of the wrong type. / Jonas After researching a bit, there are no exceptions defined in WebIDL when passing a negative number to an unsigned long parameter. The value is always converted to some type of positive value. This will result in some erratic behavior that won't generate an exception. The good news is that there is no exception that needs to be thrown :-). I will work with Eliot to make the changes to the spec and to change all int references to long. Israel
