Moving String.prototype.substr to normative part of the spec
Really necessary – given that slice is a perfect replacement?
On Friday, August 3, 2012 at 12:24 PM, David Bruant wrote:
Hi,
A code joke from a colleague [1] revealed [2] that String.prototype.substr is not part of ES5.1 as normative. Kangax tables indicate that this property is in all modern browsers [3]. I think it'd be worth moving this method to the normative part of the spec and that tests be added to test262 (since tests are on a chapter basis, I assume there is currently none for this method).
The method is in an annex (I'm mobile and can't really look it up).
With slice and substring standardized, there would be a lot repeated similar functionality
substring was in JS 1.0 in 1995, based on JDK 1.0 java.lang.String.substring -- including the quirk that misordered begin and end are swapped!
I recall adding substr at the start too, based on Perl.
I added slice based on Python in JS 1.2 in 1997, which fed into ES3.
So, Java/Perl/Python accumulation. Are we there yet?
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.
Le 03/08/2012 12:46, Rick Waldron a écrit :
On Friday, August 3, 2012 at 12:24 PM, David Bruant wrote:
Hi,
A code joke from a colleague [1] revealed [2] that String.prototype.substr is not part of ES5.1 as normative. Kangax tables indicate that this property is in all modern browsers [3]. I think it'd be worth moving this method to the normative part of the spec and that tests be added to test262 (since tests are on a chapter basis, I assume there is currently none for this method). The method is in an annex (I'm mobile and can't really look it up).
With slice and substring standardized, there would be a lot repeated similar functionality
I definitely agree, but I don't think "repetition" is a valid argument here. I'm concerned about interoperability and backward compatibility. If all browsers have the same methods, the (normative part of the) spec should include it. The web platform has all sort of overlapping technologies to solve the same use cases, but it's important to specify them all and not only a minimalist subset.
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.
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?
FWIW, String#substr is mentioned in mathias.html5.org/specs/javascript (as well as in the ES6 draft). I’ve written some tests too: 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 (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.
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.
On Aug 4, 2012, at 1:30 PM, Mathias Bynens wrote:
On 3 Aug 2012, at 20:34, David Bruant <bruant.d at gmail.com> wrote: ... FWIW, String#substr is mentioned in mathias.html5.org/specs/javascript (as well as in the ES6 draft). I’ve written some tests too: 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.
BTW, our intent is that with publication of the ES6 standard there will be no need for the non-normative "Web ECMAScript/JavaScript" document as everything that is actually normative for "Web ECMAScript" will be somewhere in the official standard. However, the current "Web ECMAScript" doc includes some stuff (eg, defineSetter) that has never been universally implemented and which will not be added to the ES6 spec.
A code joke from a colleague [1] revealed [2] that String.prototype.substr is not part of ES5.1 as normative. Kangax tables indicate that this property is in all modern browsers [3]. I think it'd be worth moving this method to the normative part of the spec and that tests be added to test262 (since tests are on a chapter basis, I assume there is currently none for this method).
David
[1] twitter.com/g_marty/status/231404856492036096 [2] twitter.com/mathias/status/231418712580845568 [3] kangax.github.com/es5-compat-table/non-standard