I'm confused, and am not very knowledgeable about FP (though I am very interested in it).
Can anyone explain how the 3 bullet points in the issue aren't already in Promises?
> Promise.of(a) will turn anything into promise.
This just looks like `Promise.resolve(a)`
> Promise#then(f) should take one function, not two.
That's applicable, but you could try limiting yourself to only using one argument.
> Promise#onRejected(f): move onRejected to prototype instead of second arg.
`Promise#catch(f)`?
The issue with `of` is that it special cases when `a` is already a Promise. Promises try hard to not be nested (a promise of a promise) but that nesting is critical for algebraic properties.
The then issue is multifarious. On one side, splitting the two uses makes the algebraic justification for then more clear, but it's not a big deal. The real issue is that `then(f)` does different things when `f` returns a Promise. This breaks in the same way that `of` did—you need to be able to discuss nested promises.
That just raises more questions. Can anyone here give a concrete example of a real world problem that is more cleanly solved with these changes to the Promise spec?
There's a lot of talk about FP and type theory here, and none about actual work. To me, all this stuff is still in the "cool to play around with at home" category. But until it affects day to day dev work, there's a whole set of people that aren't going to give the slightest fuck.
That's a seriously toxic attitude to have.
People are using monads and other FP concepts daily to simplify "day to day dev work" (here's an example [0].) The fact that it's more or less mainstream to write off a concept because it sounds "academic" is worryingly anti-intellectual in a profession that is allegedly based in analytical thinking.
> Can anyone here give a concrete example of a real world problem that is more cleanly solved with these changes to the Promise spec?
There are some in the linked github thread (which had to be reposted repeatedly until people actually stopped and read them, btw.) It's about being able to write DRY code that abstracts over not only promises, but anything else that forms a monad, like arrays, optional values, and so on.