On Wed, Oct 1, 2014 at 1:38 PM, Rick Waldron <waldron.rick at gmail.com> wrote:

>
>
> 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?
>
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141001/7b56a8b2/attachment-0001.html>

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


> ... All of this takes precedence over API surface additions, whether complete or not.

Yeah, absolutely agree that these are higher-pri.


> Time will fly, I promise.

Sure, at first glance the algorithms are trivial enough as posted above.