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

Re: IndexedDB: undefined parameters

From: Alec Flett <alecflett@chromium.org>
Date: Tue, 9 Oct 2012 14:51:41 -0700
Message-ID: <CAHWpXea5rZYWZfSvDPcU8M_m_dsOOiGp9o=EURcmd12PR8X8-g@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-webapps@w3.org
On Tue, Oct 9, 2012 at 11:37 AM, 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:
>

Someone asked me to clarify: by "this way" I meant "where passing undefined
is different than calling without the parameter" - meaning that in general,
APIs should behave the same if you call foo(undefined) as if you called
foo(). Otherwise it's notoriously hard to write anything functional (in the
CS sense) around it.

Alec


>
> 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);
>
> Alec
>
Received on Tuesday, 9 October 2012 21:52:30 GMT

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