On Wed, Oct 16, 2013 at 11:46 PM, Rick Waldron <[email protected]> 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 <[email protected]>wrote: > > > > On Wed, Oct 16, 2013 at 4:25 PM, Benjamin (Inglor) Gruenbaum < > [email protected]> wrote: > >> On Wed, Oct 16, 2013 at 9:03 PM, Andrea Giammarchi < >> [email protected]> 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 <[email protected]> >> 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
