Re: Feature-detectable API extensions?

On Tue, Aug 27, 2013 at 1:46 PM, Brendan Eich <brendan@secure.meer.net>wrote:

> 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?
>
>
That points out an issue with extensibility of the Indexed DB API here. The
the result of a continue() call is delivered asynchronously to a previously
created "request" object handed to script when the cursor was created; the
request is known internally by the cursor but there's no path from cursor
to request from script. A polyfill would need to wrap several other methods
such as openCursor(), and would rely on unhooking existing event handlers
from the request while it's doing manual iteration.


>  * 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.
>
>
Good advice; Jonas, weren't you prototyping open(dictionary) to handle
specifying storage type and other options?


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