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
