Moving String.prototype.substr to normative part of the spec
brendan at mozilla.org
Sat Aug 4 13:34:38 PDT 2012
TC39 won't agree to all the trash in Annex B becoming
normative-mandatory. Normative-optional is enough for browsers and other
embeddings that want full interop. For the future, do we really want
stinking Y2K-broken-by-design getYear, copied from Gosling's
1995-or-older java.util.Date, to be mandated for all JS embeddings?
I do not. From time to time we have to prevent a fork of ECMA-262 into
some "mobile" or "small embedded system" variant, which (a) has no room
for such junk; (b) has no interop need. The web is not everything. I
would venture that Node.js doesn't want getYear and other cruft from
Annex B, either.
Mathias Bynens wrote:
> On 3 Aug 2012, at 20:34, David Bruant<bruant.d at gmail.com> wrote:
>> Le 03/08/2012 12:58, Allen Wirfs-Brock a écrit :
>>> substr is in Annex B, which in ES5.1 is an informative annex. In ES6, the content of Annex B will be optional normative. Required for web user agents, but optional for other hosts.
>> Ok. Is it planned to extend ES6-test262 scope to include tests for Annex B?
>> I'm wondering what's the downside of adding it in the normative part of the spec. It's in every browser, it's in Node.js, it's likely to be in MongoDB JS (I haven't tested, but it's based on SpiderMonkey 1.7, and soon V8), likely in all the mostly used JS platforms (which are often based on browser-included JS interpreters).
>> It's likely that platforms that support ES6 without substr will suffer from interoperability from libraries/modules that use it and rely on it and will be forced to add substr anyway.
>> I guess I should ask the question: Are there known and used platforms that do not include substr? If the answer is no, then it probably should get in the spec for the sake of interoperability.
> I couldn’t agree more. IMHO, the whole Annex B should be made normative for all engines for interoperability/compatibility reasons.
> “Support Existing Content” is one of the [HTML] Design Principles (http://www.w3.org/TR/html-design-principles/#support-existing-content), and it would make sense to apply it to ECMAScript as well.
> Just my €0.02.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss