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