Should String.prototype.split accept variable arguments optionally?

Rick Waldron waldron.rick at gmail.com
Wed Oct 16 13:46:30 PDT 2013


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/ed0df980/attachment-0001.html>


More information about the es-discuss mailing list