Standardisation Notes

[pemrouz]

Some fairly minor but potentially useful spec-related notes/reflections thought it would be worth writing up/sharing/discussing (/cc @littledan @domenic @bterlson @ljharb @robpalme @syg):

1. Introduce a Symbol.reducer/call/receiver?

To add: I've just noticed that this would also essentially define the other half of the behaviour of how the spread operator syntax works { ...object } (i.e. as iteration protocol is used to get values during spread, this would define how to apply values).

2. Symbol.iterator gaps?

From the perspective of looking at all the 36 permutations, crossing the t's and dotting the i's, there are three things for which there isn't a Symbol.iterator, but seems useful to have:

• Object: This seems so obvious that I imagine there was probably a reason it hasn't been done already? Does anyone know why? Setting it as the generator form of Object.entries matches really well with setting the reducer as the generator form of Object.fromEntries.

• Function: This may seem less obvious, but calling a function to generate values also works pretty well (as well as the inverse), and would be much simpler in many cases where you think you might need a generator:

  const input = (i = 0) => () => i++
  
  // returns [3, 9, 15]
  transform(input(), [])(
  map(v => v * 3)
  , filter(v => v % 2)
  , until(3)
  )

• Number: Reducing to a number (+=) is a very common one. At a minimum the iterator for this could yield the number itself to be symmetrical. However, I'm tempted to say that the iterator for a number counting up to that value would be so much significantly more useful instead.

~3. iterator.done (flag and promise)~

Scratch these, these were trivial amendments, but I'm now thinking I can get rid of and do without these anwyay, will revisit

*4. `.prototype.transform`**

As mentioned here, all other transformations could be expressed in these terms. A consistent .transform property could be added where applicable, and/or inlined .map/.filter/.reduce could also wrap this. This would lead to a consistent, predictable, fast and extensible "transformation protocol" in JavaScript. With the backpressure semantics that dropped out, I (think?) this even covers WHATWG Stream cases pretty well, but would need more thought/confirmation with that.

Would be good to know if people think any of this is a good idea, and if so feedback/suggestions/additional context.

[ljharb]

Having objects be iterable means that boolean, numbers, regexes, functions, etc would all be iterable, and it’s not clear what that would mean. I don’t think there’s any clear meaning for a non-generator function being iterable, for example; and i don’t think it makes sense to have numbers be iterable - what would Math.PI iterate to? What about -3.2? What about NaN?

Since i have no context on this repo (this thread was the first I’ve heard about it), I’m not sure what the goal is. Could you elaborate a bit?

[beardedtim]

As purely a user of this package, I would not see the need for the Number type being iterable. It seems that any sort of reduction of numbers should be up to me the user to make not the package itself. Or put in other words, it's a great use-case but not for the library overall.