- From: João Eiras <joaoe@opera.com>
- Date: Wed, 10 Oct 2012 13:17:44 +0200
- To: public-webapps@w3.org
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 UTC