W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: IndexedDB: undefined parameters

From: João Eiras <joaoe@opera.com>
Date: Wed, 10 Oct 2012 13:17:44 +0200
To: public-webapps@w3.org
Message-ID: <op.wlymzuoa2q99of@joaoe>
On Tue, 09 Oct 2012 20:37:36 +0200, Alec Flett <alecflett@chromium.org>  
wrote:

> On Tue, Oct 9, 2012 at 11:12 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
>> On 10/9/12 1:52 PM, Joshua Bell wrote:
>>
>>> The IDB spec does not have [TreatUndefinedAs=Missing] specified on
>>> openCursor()'s arguments (or anywhere else), so I believe Chrome's
>>> behavior here is correct.
>>>
>>
>> It looks correct as the spec is currently written.
>>
>> It's not clear to me why the spec is written the way it is.  It could  
>> just
>> as easily define that if the "any" value is undefined, it's ignored.   
>> Or it
>> could use [TreatUndefinedAs=Missing], indeed.
>
>
> I have to say, as a developer it can be really frustrating to write
> abstractions on top of APIs that behave this way, when you want to say
> something like:
>
> var direction;
>  var range;
>
> if (condition1)
>    direction = 'prev';
> else if (condition2)
>    direction = 'prevuniq';
>
> if (condition3) {
>   range = range1;
> else if (condition4)
>   range = range2;
>
> return source.openCursor(range, direction);
>

According to the issue here, it would have to be written as

$ if (range && direction) return source.openCursor(range, direction);
$ else if(range) return source.openCursor(range);
$ else return source.openCursor(range);

which is a bit annoying, specially if the parameters are being already  
passed to a wrapper function, e.g.:

$ function open_cursor(range){
$  return os.openCursor(range, 'next');
$ }
$ open_cursor();
Received on Wednesday, 10 October 2012 11:18:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:55 GMT