On Wed, Oct 1, 2014 at 1:38 PM, Rick Waldron <[email protected]> wrote:
> > > On Wed, Oct 1, 2014 at 4:26 PM, Dmitry Soshnikov < > [email protected]> wrote: > >> On Wed, Oct 1, 2014 at 12:59 PM, Rick Waldron <[email protected]> >> wrote: >> >>> >>> >>> On Wed, Oct 1, 2014 at 3:51 PM, Jeremy Martin <[email protected]> wrote: >>> >>>> Not sure if this is sufficient motivation to accelerate the timeline >>>> >>> >>> >>> It's not about "motivation", it's about realistic time constraints. TC39 >>> has already had to push out 6 months and that was not taken well by both >>> the community and by Ecma. Further delay is not an option. >>> >>> >> Just out of curiosity: what's the realistic "out of time" issue here? >> Actually, I think having a ready and working algorithm draft on github gist >> will help discussing this faster and in realistic time frames (I've >> should've done before starting this thread; otherwise, these are "too >> abstract time-stoppers" for me -- unless you know specific big issues that >> will be hard to implement). >> > > If this was really pressing, why wasn't it on any meeting agendas in the > last year? > > I'm sorry, as mentioned at the beginning of this thread, I unfortunately missed this part of the spec when the decisions were made. And since we just recently started to polyfill the `Map` in our codebase following the spec, I was surprised that neither `map`, nor `filter` are actually in the spec. I thought there were some real big issues, and wanted to clarify them. If it's only "out of time", I'd of course propose it for the agenda. > The spec must be essentially finished by the next meeting (the last > meeting in 2014). Finalizing the Loader details, super class instantiation > (you might recall that was an issue recently), RegExp work in Annex B (may > require lexical grammar changes), revising, reviewing, etc. (I know there > is a lot more here)... All of this takes precedence over API surface > additions, whether complete or not. Additionally, the committee is trying > establish a new process for all new features. Domenic could've tried to > push Array.prototype.contains into ES6, but he's following the process. > https://github.com/tc39/ecma262 > > Yeah, absolutely agree that these are higher-pri. > > > > >> >> >>> >>> >>>> for adding suitable parallels from Array.prototype, but it may be worth >>>> recalling what developers did last time there were obvious "gaps" in what a >>>> native prototype provided. Array#contains, anyone? >>>> >>> >>> As a community we'll simply have to reject the use of code that directly >>> modifies built-ins. This is also not a very strong argument in the ES6 >>> world where built-ins can be subclassed. >>> >>> >> Actually the case with "borken" `Array#contains` which is so actively >> discussed, is a good example. I think very likely `Map#map`, and >> `Map#filter` will be added manually if not in ES6. >> > > See my response, I doubt that a one year wait until ES7 will really ruin > the chances for map and filter methods. In the meantime, write the spec, > get it added to https://github.com/tc39/ecma262 and enforce the semantics > on all userland implementations. Time will fly, I promise. > Sure, at first glance the algorithms are trivial enough as posted above. Dmitry
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
