search

tc39 / proposal-flatMap

proposal for flatten and flatMap on arrays
https://tc39.github.io/proposal-flatMap
214 stars 19 forks source link

Do we still want the `thisArg`? #43

Closed benlesh closed 6 years ago

benlesh commented 6 years ago

Is thisArg still relevant in a world where bind is so much more efficient? I understand it might be provided out of symmetry with other methods like map or filter, but:

  1. most people will be using arrow functions now
  2. bind is much much faster than it used to be.
  3. When this pattern is taken as a solid example out to other libraries they get harder to read: e.g. someType.method(myFunction, arbitraryObject) vs someType.method(myFunction.bind(arbitraryObject))
  4. If you ever wish to add a feature for result mapping to flatMap you'll be stuck behind a thisArg, and how will you control the thisArg for that? array.flatMap((a, i) => toOtherArray(a), (a, b, i, ii) => a + b) (where b and ii are from the inner array)... (I'm not suggesting this as a feature, it's a hypothetical)
benlesh commented 6 years ago

Tangent: In a world with Turbofan, the hypothetical addition in 4 above should just be array.flatMap((a, i) => toOtherArray.map((b, ii) => a + b)).

(Again, that's a total tangent, not related to what I was talking about above, which is asking whether we really want the thisArg or not)

ljharb commented 6 years ago

I agree that thisArg is not useful.

However, because of symmetry, I think it needs to be on flatMap.

michaelficarra commented 6 years ago

Agreed with @ljharb. It pretty much has to be there for symmetry, but I don't expect many people to use it. Thanks for opening the issue for visibility, but I'd rather avoid any unnecessary changes to the proposal to maximise its chances of advancing to stage 3 at the next meeting.

benlesh commented 6 years ago

@ljharb that's fine! :) I don't disagree... I just wanted to try. I've never liked thisArg, and I keep being asked and/or needing to add it to RxJS. haha.