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

Re: Feature-detectable API extensions?

From: Norbert Lindenberg <ecmascript@lindenbergsoftware.com>
Date: Tue, 27 Aug 2013 14:10:11 -0700
Cc: Norbert Lindenberg <ecmascript@lindenbergsoftware.com>, public-script-coord <public-script-coord@w3.org>
Message-Id: <69F2ACBB-2E75-44F0-A968-FF4F1CFE7B82@lindenbergsoftware.com>
To: Joshua Bell <jsbell@google.com>

On Aug 27, 2013, at 13:21 , Joshua Bell <jsbell@google.com> wrote:

> 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" ?

Are there argument values for the second argument that are invalid and will result in an exception? That's what can be used to detect whether String.prototype.localeCompare and a few other methods are implemented according to ECMA-402 or according to ECMA-262:
http://norbertlindenberg.com/2012/12/ecmascript-internationalization-api/index.html#Detection

Note though that these *locale* methods were always documented in ECMA-262 with a warning that a new parameter was likely to be added.

Norbert
Received on Tuesday, 27 August 2013 21:10:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC