Should String.prototype.split accept variable arguments optionally?
andrea.giammarchi at gmail.com
Wed Oct 16 13:46:06 PDT 2013
also, to reply your question "Are you against changes like `.contains` or
Absolutely not, and these are new methods indeed. Perfectly in line with
what you wrote:
> Why have `str.contains` if you can just do `~str.indexOf`. Why have
`.startsWith`, or `.indexOf` on arrays?
You are asking to change a method that is like that since ever. Using your
examples is like asking to return false on `indexOf` because new comers
don't understand that -1 is truthy value, you know what I mean?
String#split does what it does and it should keep doing that, even if I've
never used an Array or multiple arguments on it (also never felt the need
Hope I've answered your questions.
As Summary: Every jQuery programmer could write a function that accept an
array and does the split with that, no need to ask to change core legacy
(my only point in here, really).
Feel free to propose a new method ;-)
On Wed, Oct 16, 2013 at 1:40 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:
> It does break in many ways as also Brendan said.
> `''.split(what, ever)`
> would break
> you have no idea what you could find in legacy code ... so whatever a 12+
> years old legacy does shold keep doing like that and if you really want to
> put your array in there follow Brendan hint and create your own method.
> Once again, just my 2 cents
> On Wed, Oct 16, 2013 at 1: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
>> 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
>> 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?
>> On Wed, Oct 16, 2013 at 9:21 PM, Brendan Eich <brendan at mozilla.com>
>> > 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).
>> What about the version with the overload accepting an Array instead? It
>> seems more backwards compatible than the varargs version.
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss