- From: Israel Hilerio <israelh@microsoft.com>
- Date: Mon, 15 Aug 2011 17:29:00 +0000
- To: Aryeh Gregor <ayg@aryeh.name>, Jonas Sicking <jonas@sicking.cc>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>, Jim Wordelman <jaword@microsoft.com>, Adam Herchenroether <aherchen@microsoft.com>, "Victor Ngo" <vicngo@microsoft.com>
On Sunday, August 14, 2011 4:09 PM, Aryeh Gregor wrote: > On Fri, Aug 12, 2011 at 6:16 PM, Jonas Sicking <jonas@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
Received on Monday, 15 August 2011 17:29:31 UTC