- From: Norbert Lindenberg <ecmascript@lindenbergsoftware.com>
- Date: Tue, 27 Aug 2013 14:10:11 -0700
- To: Joshua Bell <jsbell@google.com>
- Cc: Norbert Lindenberg <ecmascript@lindenbergsoftware.com>, public-script-coord <public-script-coord@w3.org>
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