Should String.prototype.split accept variable arguments optionally?

Benjamin (Inglor) Gruenbaum inglor at gmail.com
Wed Oct 16 14:11:08 PDT 2013


On Wed, Oct 16, 2013 at 11:46 PM, Rick Waldron <waldron.rick at gmail.com>
 wrote:

> > What about the version with the overload accepting an Array instead? It
seems more backwards compatible than the varargs version.

I meant the version accepting an array `.split([a,b,c])` rather than
`.split(a,b,c)` but the 12 years and the two lightly arguments by Andrea
and Brendan convinced me that adding something like this to .split() is too
risky.

> in the future, tell students to construct new Arrays of numbers (that may
have 1 entry) with Array.of():

Nice! I've almost never had to do Array(..items), usually I just suggest a
literal in the cases they do :) Thanks for the tip though, I should really
read the ES6 current spec from start to end.

On Wed, Oct 16, 2013 at 11:46 PM, Rick Waldron <waldron.rick at gmail.com>wrote:

>
>
>
> On Wed, Oct 16, 2013 at 4:25 PM, Benjamin (Inglor) Gruenbaum <
> inglor at gmail.com> wrote:
>
>> On Wed, Oct 16, 2013 at 9:03 PM, Andrea Giammarchi <
>> andrea.giammarchi at gmail.com> wrote:
>> > How could change 12+ years of legacy be considered inexpensive ?
>>
>> This proposal does not break anything, the only thing that will/might
>> work differently is people passing an array to .split right now and
>> expecting something like splitting on `firstElem,secondElem...`. Current
>> usages of .`split` with a string or with a regular expression will continue
>> to function exactly the same, the only thing happening here is adding an
>> overload for an array.
>>
>> > Non "highly trained professionals" should be simple things or try to
>> learn something new that won't hurt... so please make it simpler"
>>
>> If we can make life the easier without breaking anything, why not? A lot
>> of people use JavaScript on the web in practice for making websites
>> dynamic, most of those people are not me and certainly not you but they're
>> still probably the majority. How many so called ""jQuery programmers"" are
>> there?
>>
>
> As one of jQuery's own representatives to Ecma/TC39, I still stand by my
> original response. After reading through those links, I agree with Andrea:
> it's a handful of people that just need time and motivation to learn.
>
>
>> I'm not sure taking a common use case like `.split` on multiple
>> delimiters and removing a skill (Regular Expressions) they had to know
>> before in order to write code they understand and by that making the
>> language more accessible to them is not a good idea.
>>
>> There are and have been such API changes in the language. Why have
>> `str.contains` if you can just do `~str.indexOf`. Why have `.startsWith`,
>> or `.indexOf` on arrays?
>>
>> I'm not saying we _should_ add a `.split` third overload in addition to
>> the already existing two. I do however think it is an interesting idea that
>> in practice a lot of developers, especially ones who do not remember the
>> abstract comparison algorithm by heart can possibly benefit from.
>>
>> Are you against changes like `.contains` or `.startsWith` too? What do
>> you think is the criterea for such additions to the language?
>>
>
> I'm all for new additions, but nothing is free and changing an existing
> thing is potentially even more expensive. Brendan's response is the most
> compelling.
>
>
>>
>
>
>>
>> On Wed, Oct 16, 2013 at 9:21 PM, Brendan Eich <brendan at mozilla.com>
>>  wrote:
>> > It's hard to add extra optional arguments to a long-standing built-in.
>> People write code that passes an extra arg that has been ignored till the
>> change; browsers that try shipping the new version then break that content,
>> user blames browser (rightly so) but also the page, sometimes (not right).
>>
>> Agreed. Even without compatibility issues, I get confused questions from
>> students regarding the behavior of methods changing behavior based on
>> number of arguments (`Array` for example) way more often than I'd expect.
>> (and props on the spec, being able to send students there in such cases is
>> extremely enabling imo and a great exercise on its own).
>>
>
> Too late to change Array arg handling. In the future, tell students to
> construct new Arrays of numbers (that may have 1 entry) with Array.of():
>
> Array.of(42).length === 1;
>
> (vs. Array(42).length === 42; )
>
>
>
>
>>
>> What about the version with the overload accepting an Array instead? It
>> seems more backwards compatible than the varargs version.
>>
>
> What version is that?
>
>
>
>>
>> Regexps suck away oxygen too, as others note. My suggestion is to focus
>>> fire for greater effect. If we need a new variable-split, we want a new API.
>>>
>>
>> I actually like the existing API for the most part and just wish it made
>> life easier at times. Especially for learners. I'd like to teach my nephew
>> JavaScript as a first language and I don't want to go anywhere near regular
>> expressions.
>>
>
> Again, this is too subjective.
>
>
> Rick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131016/a883751f/attachment.html>


More information about the es-discuss mailing list