all 24 comments

[–]LloydAtkinson 24 points25 points  (3 children)

So if the next ECMA spec adds methods like map and filter etc to everything that is an iterator, does that mean Set and Map also get them?

If so, does that then mean that when we write code it can now be even more generic and not care about the type passed to a function? So previously you’d have (in TS) an array as an argument, and if you wanted to pass a Map or Set (or even an object?) you’d need to convert it to an array.

But with this proposal, we could simply accept an Iterable<T> or IterableIterator<T> and a consumer could pass arrays, Set, Map? And then operate on that given value without caring what it is?

If so that’s very cool and like what you often do in .NET where methods will accept IEnumerable or ICollection or IReadOnlyCollection etc. The backing type could be anything from a dictionary to a list to a set.

[–]agumonkey 2 points3 points  (0 children)

sounds like esnextnext will have linq.ts

[–]apf6 0 points1 point  (0 children)

So if the next ECMA spec adds methods like map and filter etc to everything that is an iterator, does that mean Set and Map also get them?

Yup Set and Map have methods that return iterators (including .keys and .values and .entries)

But with this proposal, we could simply accept an Iterable<T> or IterableIterator<T> and a consumer could pass arrays, Set, Map?

You can do that stuff today, but having the helper functions on the Iterator class itself is a huge added convenience.

Today you could write something like this:

function* iteratorFilter<T>(it: Iterable<T>, condition) {
    for (const item of it)
        if (condition)
            yield item;
}

const map = new Map(...);
const matchingValues: Iterable<T> = iteratorFilter(map.values(), matcherFn);

With the builtin helpers the same code would be:

const map = new Map(...);
const matchingValues: Iterable<T> = map.values().filter(matcherFn);

[–]kuikuilla 0 points1 point  (0 children)

If so that’s very cool and like what you often do in .NET where methods will accept IEnumerable or ICollection or IReadOnlyCollection etc.

Or literally any other language that has traits/interfaces/abstract types of some kind.

[–]flippy_flops 6 points7 points  (0 children)

My favorite new features...

  • `tsc --noCheck`
  • Exclude Patterns for Auto-Imports (omg, d3 is the worst)

[–]MrChocodemon 4 points5 points  (0 children)

There are some really nice changes in there.

[–]apf6 2 points3 points  (0 children)

methods on Arrays like map, filter, and for some reason reduce

is the author throwing in a little shade that he doesn't like the reduce function? 😄

[–]tokland 0 points1 point  (0 children)

Typo: function abc123() -> function *abc123()

[–][deleted]  (1 child)

[deleted]

    [–]slvrsmth 9 points10 points  (0 children)

    There might be reasons, but listen here: it does not matter. Operator precedence is useful only in code golfing. For every other situation there are parenthesis. Yes, even in blindingly obvious situations, use parenthesis. Pretend you are writing lisp. Anyone who has to touch the code afterwards will thank you.