Re: Feature-detectable API extensions?

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").

/be

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