Discuss
  • `.toArray()` for all generators

`.toArray()` for all generators

# Forbes Lindesay (12 years ago)

It would be nice from a readability point of view if iteratable.toArray() could always be used as a substitute for Array.from(iteratable). Is there a way that could be neatly achieved? It would also be nice if methods like .map and .filter existed on iteratables. C# does this via the concept of extension methods, but I wonder whether something similar could be achieved here, at least in the case of built in iteratables?

# Axel Rauschmayer (12 years ago)

On Aug 28, 2013, at 17:02 , Forbes Lindesay <forbes at lindesay.co.uk> wrote:

It would be nice from a readability point of view if iteratable.toArray() could always be used as a substitute for Array.from(iteratable). Is there a way that could be neatly achieved?

For me, [ ... iterable ] would be good enough. Relatively readable and concise.

It would also be nice if methods like .map and .filter existed on iteratables. C# does this via the concept of extension methods, but I wonder whether something similar could be achieved here, at least in the case of built in iteratables?

It would be lovely to have a module with tool functions for this, similar to Python’s itertools. docs.python.org/3/library/itertools.html

# Forbes Lindesay (12 years ago)

The thing about .map and .filter is that it would be easy enough to create functional versions:

function* map(array, fn) {
  for (var x of array) {
    yield fn(x)
  }
}

But harder to create methods:

Iteratable.prototype.map = function(fn) {
  for (var x of this) {
    yield fn(x)
  }
}

The reason being that not all iteratables share a prototype (to my knowledge).

# Claude Pache (12 years ago)

Note that an equivalent of both .map and .filter already exists in ES6: its name is "generator expression". For instance:

array.filter(pred).map(transf)

becomes:

(for (let x of iter) if (pred(x)) transf(x))
# Rick Waldron (12 years ago)

On Wed, Aug 28, 2013 at 11:02 AM, Forbes Lindesay <forbes at lindesay.co.uk> wrote:

It would be nice from a readability point of view if iteratable.toArray() could always be used as a substitute for Array.from(iteratable).

Since both Array.from and [..spread] already covers every single iterable and arraylike case now and forever, there is very little benefit (none?) in also specifying a toArray method on the prototype of every object that is capable of creating an iterable.

# Andrea Giammarchi (12 years ago)

I completely agree with Rick plus this is what I meant in the other thread when I've said I don't see the urge/need to deal with Iterators => Arrays

if not ending up with waste of resources as the one proposed here.

Somebody will need to write specs, tests, and implementations while we have all possible tools to add a toArray method and all possible tools to have something that works nicely with for/of ... so, why even bothering with all this sugar when much more has to be improved?

Again, just my 2 cents.

# Andreas Rossberg (12 years ago)

In addition to what others have already said, note that iterators model streams that are not necessarily finite. Hence, a toArray method would not generally be well-defined.

# Forbes Lindesay (12 years ago)

This all seems fair enough. My concern is mostly that the blob.method(fn) syntax seems much easier to get your head around (as someone familiar to JavaScript) than the [for (let x of iter) if (pred(x) transf(x)]. I always used the traditional syntax for LINQ in C# as well (which gave you both options). Perhaps I'm just too set in my ways though. I'm happy to accept that it's probably easy enough to just rely on Array.from when you want an array from an iterator.

# Andrea Giammarchi (12 years ago)

plus any time you want you can GenericPrototype.toArray = function(){return Array.from(this)}; ... no need to put in specs your C# flavor, somebody else Python flavor, Ruby, Java, or Haskell ... JS would look like the tower of babel ^_^

note: it kinda does already in specs V6 and early 7