- From: Joshua Bell <jsbell@google.com>
- Date: Tue, 27 Aug 2013 13:21:23 -0700
- To: public-script-coord <public-script-coord@w3.org>
- Message-ID: <CAD649j7JA6rHSrRg60vaJY+4w9mFXq4a_Uv-HdjWtKHxF1mxAg@mail.gmail.com>
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. 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) * 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) * 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. Doesn't mean we should reject it, but I'm interested in what the next iteration of the question would be. Other thoughts?
Received on Tuesday, 27 August 2013 20:21:50 UTC