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:

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

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

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