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

RE: IndexedDB: undefined parameters

From: Aaron Powell <me@aaron-powell.com>
Date: Tue, 9 Oct 2012 22:20:55 +0000
To: Alec Flett <alecflett@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <6ED5F3CF043F35489214293D74026A24211E2C66@EXMBX12.netplexity.local>
I'll agree that it is a bit on the confusing side, I'm pretty sure that there's a point in the spec that it indicates that 'null' is how to represent a not provided key but supporting 'undefined' would make it simpler to work with the API. The problem I can see with that is there are several shipped implementations of the spec that this would break for (if I recall correctly IE10 will raise a DataError on undefined but not null).

Aaron Powell
MVP - Internet Explorer (Development) | FunnelWeb Team Member<http://funnelweblog.com/>

http://apowell.me<http://apowell.me/> | http://twitter.com/slace | Skype: aaron.l.powell | Github<http://github.com/aaronpowell/> | BitBucket<http://hg.apwll.me/>

From: alecflett@google.com [mailto:alecflett@google.com] On Behalf Of Alec Flett
Sent: Wednesday, 10 October 2012 8:52 AM
To: Boris Zbarsky
Cc: public-webapps@w3.org
Subject: Re: IndexedDB: undefined parameters


On Tue, Oct 9, 2012 at 11:37 AM, Alec Flett <alecflett@chromium.org<mailto:alecflett@chromium.org>> wrote:

On Tue, Oct 9, 2012 at 11:12 AM, Boris Zbarsky <bzbarsky@mit.edu<mailto: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 Wednesday, 10 October 2012 15:47:49 GMT

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