Re: IndexedDB: undefined parameters

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.


Rob.

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
>>
>
>