On Wed, Oct 1, 2014 at 4:26 PM, Dmitry Soshnikov <dmitry.soshnikov at gmail.com
> wrote:

> On Wed, Oct 1, 2014 at 12:59 PM, Rick Waldron <waldron.rick at gmail.com>
> wrote:
>
>>
>>
>> On Wed, Oct 1, 2014 at 3:51 PM, Jeremy Martin <jmar777 at gmail.com> 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?

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




>
>
>>
>>
>>> 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.

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141001/93539352/attachment-0001.html>

> Just out of curiosity: what's the realistic "out of time" issue here?

If this was really pressing, why wasn't it on any meeting agendas in the
last year?

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

> 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.