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.
/be
Mathias Bynens wrote:
On 3 Aug 2012, at 20:34, David Bruant<[email protected]> 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?
FWIW, String#substr is mentioned in http://mathias.html5.org/specs/javascript/
(as well as in the ES6 draft). I’ve written some tests too:
http://mathias.html5.org/tests/javascript/string/
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.
This is why it’s been included in Web ECMAScript/JavaScript, FWIW.
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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
