W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

Re: Feature-detectable API extensions?

From: Brendan Eich <brendan@secure.meer.net>
Date: Tue, 27 Aug 2013 13:46:57 -0700
Message-ID: <521D1041.9060707@secure.meer.net>
To: Joshua Bell <jsbell@google.com>
CC: public-script-coord <public-script-coord@w3.org>
Joshua Bell wrote:
> We're considering extending an existing method on a browser object 
> with a second, optional parameter. The API under consideration is the 
> "continue" method on the IDBCursor in the Indexed DB API, but I'm 
> interested in general thoughts.
> Existing code, or that didn't need the new capabilities would use:
> myCursor.continue("my key");
> New code that needed the extra capabilities could use:
> myCursor.continue("my key", {primaryKey: "my primary key"});
> Now the problem: the new call would fail silently on older 
> implementations; it would yield a value that would be incorrect, but 
> not in a way that's trivial to detect.

That says this is a backward-incompatible extension.

> How should the API be designed to allow feature detection, without 
> "designing for the past" ?
> Various solutions:
> * Use a new method, e.g. continueWithPrimaryKey(), and detect with 
> ('continueWithPrimaryKey' in IDBCursor)

This works best. Is a polyfill possible?

> * Rely on a library like Modernizr to implement a test - in this case, 
> by creating a scratch database, populating it with data, and probing 
> the behavior; doable, but with a minimum of 3 turns of the event loop 
> (open database, populate+open cursor, call continue, check result)

Lost me after "Rely on" ;-).

> * Change the method signature in such a way that it would throw an 
> exception in older implementations, e.g. continue({key: ..., 
> primaryKey: ...}).
> Note that the last approach works this time we upgrade the API because 
> passing an object happens to throw with the existing API, but that 
> approach would fail next time we upgrade the API to take yet another 
> optional param.

Seems bogus to switch from n-ary when n goes past 1 back to 1-ary with 
parameters passed in an object.

New method wins cleanly in my view, with zero doubt if polyfills are 
doable (they do not have to be "perfect").

Received on Tuesday, 27 August 2013 20:47:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:18 UTC