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

Re: IndexedDB: undefined parameters

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 10 Oct 2012 15:51:33 -0700
Message-ID: <CA+c2ei8pQ3aCr=Ez=eH8vZnGqY62BcU5kBQo_cZrwa-ZLfY4Eg@mail.gmail.com>
To: Robert Ginda <rginda@chromium.org>
Cc: Alec Flett <alecflett@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
On Tue, Oct 9, 2012 at 3:04 PM, Robert Ginda <rginda@chromium.org> wrote:
> On Tue, Oct 9, 2012 at 2:51 PM, Alec Flett <alecflett@chromium.org> wrote:
>>
>>
>>
>> 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.
>>
>
> I completely agree here.  But I never, ever use the symbol-known-as
> "undefined" in script, since it's actually a write-able variable.  I'd
> suggest also treating null as missing if possible.

FWIW, ES6 is going to treat the undefined value as "not passing a
parameter" when it comes to functions that have default values. So all
of the following functions will log 42:

function f1(a = 42) {
   console.log(a);
}
function f2({ a = 42 }) {
  console.log(a);
}
f1();
f1(undefined);
f2();
f2({});
f2({ a: undefined });

In anticipation of ES6 formally defining this, WebIDL has already
switched to this and so the IndexedDB spec actually already defines
that passing 'undefined' as the first argument to openCursor should
behave the same as not passing a first argument at all.

As for null, the intent was that 'null' would be interpreted as 'not
defined' and thus the same as undefined. Though this isn't very clear
in the spec.

/ Jonas
Received on Wednesday, 10 October 2012 22:52:31 GMT

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