3 ms·

Very true, You have to decide at some point whether you’re going to have everything be callable, or everything be an object, and thereafter be consistent. The f

Very true, You have to decide at some point whether you’re going to have everything be callable, or everything be an object, and thereafter be consistent. The functions `takeIterable` and `statefulMapIterableWith` are both written to take and return iterables, but you could write parallel versions operating directly on callables. You probably want them to return the same thing they consume. A more full-featured utility might pattern match on what it is given and return the same form.

voyou 12y ago
Sure, but it's takeIterable and statefulMapIterableWith which I was wondering about. They are themselves callables which return iterables. Is there any reason not to write them as generator functions?
- picks_at_nits 12y ago
  These would have been excellent questions for Christine to ask! I made an es6 fiddle: http://www.es6fiddle.net/i6fralh4/ http://www.es6fiddle.net/i6fralh4/ Is this what you mean? --- const takeIterable = (numberToTake, iterable) => ({ [Symbol.iterator]: function* () { let remainingElements = numberToTake; for (let element of iterable) { if (remainingElements-- <= 0) break; yield element; } } }); const x = takeIterable(3, [1, 2, 3, 4, 5]); console.log(...x); console.log(...x); console.log(...x); //=> [1, 2, 3] [1, 2, 3] [1, 2, 3] function* takeGenerator (numberToTake, iterable) { let remainingElements = numberToTake; for (let element of iterable) { if (remainingElements-- <= 0) break; yield element; } }; const y = takeGenerator(3, ["a", "b", "c", "d", "e"]); console.log(...y); console.log(...y); console.log(...y); //=> [“a”, “b”, “c”] [] []
  - voyou 12y ago
    Ah, the penny drops. Thanks. I've actually been bitten by not paying attention to the same distinction in python, which I evidently haven't quite learned the lesson of yet.
  - jessaustin 12y ago
    That's great; you've really made this clear. In python, one would just use itertools.tee() to get multiple bites at a particular iterator, rather than relying on sugary syntax to instantiate the iterator multiple times; perhaps ES6 should have something similar? I have to say, this "Symbol.iterator" magic string seems like an even less felicitous way to write this than python's dunderous __iter__() function. Maybe coffeescript or one of its forks can help ES explore a more reasonable way to write this.
    - picks_at_nits 12y ago
      Well, __iter__ was baked into Python decades(?) ago, so there’s no danger anybody might have their own __iter__ methods that mean something else. But now that JS is adding iteration methods to the language, there are lots of libraries and frameworks that have their own incompatible ways of greenspunning these features. The [Symbol.iterator] expression resolves to a string that is guaranteed to be unique, so there is no possibility of breaking backwards-compatibility with someone who picked the exact same magic name. (There’s a major headache involved when code crosses execution contexts, I don’t pretend to understand how that works yet.)

voyou 12y ago

Sure, but it's takeIterable and statefulMapIterableWith which I was wondering about. They are themselves callables which return iterables. Is there any reason not to write them as generator functions?

picks_at_nits 12y ago
These would have been excellent questions for Christine to ask! I made an es6 fiddle: http://www.es6fiddle.net/i6fralh4/ http://www.es6fiddle.net/i6fralh4/ Is this what you mean? --- const takeIterable = (numberToTake, iterable) => ({ [Symbol.iterator]: function* () { let remainingElements = numberToTake; for (let element of iterable) { if (remainingElements-- <= 0) break; yield element; } } }); const x = takeIterable(3, [1, 2, 3, 4, 5]); console.log(...x); console.log(...x); console.log(...x); //=> [1, 2, 3] [1, 2, 3] [1, 2, 3] function* takeGenerator (numberToTake, iterable) { let remainingElements = numberToTake; for (let element of iterable) { if (remainingElements-- <= 0) break; yield element; } }; const y = takeGenerator(3, ["a", "b", "c", "d", "e"]); console.log(...y); console.log(...y); console.log(...y); //=> [“a”, “b”, “c”] [] []
- voyou 12y ago
  Ah, the penny drops. Thanks. I've actually been bitten by not paying attention to the same distinction in python, which I evidently haven't quite learned the lesson of yet.
- jessaustin 12y ago
  That's great; you've really made this clear. In python, one would just use itertools.tee() to get multiple bites at a particular iterator, rather than relying on sugary syntax to instantiate the iterator multiple times; perhaps ES6 should have something similar? I have to say, this "Symbol.iterator" magic string seems like an even less felicitous way to write this than python's dunderous __iter__() function. Maybe coffeescript or one of its forks can help ES explore a more reasonable way to write this.
  - picks_at_nits 12y ago
    Well, __iter__ was baked into Python decades(?) ago, so there’s no danger anybody might have their own __iter__ methods that mean something else. But now that JS is adding iteration methods to the language, there are lots of libraries and frameworks that have their own incompatible ways of greenspunning these features. The [Symbol.iterator] expression resolves to a string that is guaranteed to be unique, so there is no possibility of breaking backwards-compatibility with someone who picked the exact same magic name. (There’s a major headache involved when code crosses execution contexts, I don’t pretend to understand how that works yet.)