> 1. Committee "do both" / union proposals smell and bloat -- this is a > problem _per se_.
Irony: .then() does both things and there's no way to stop it from doing both. The "do both" committee is actually not wanting both, it wants to only do one thing. We insist, we demand on having a way to NOT do both: we want .chain, and those who want .then can keep recursing through .chain while it's still a promise: that's your .then. Irony aside, this is really a very handwavy thing. How much bloat is it? Is the smell going to effect the neighbors? Is this like Fabreeze level spec smell or will knock over an elephant level bad small? Anyways, To use "both" as loaded ammunition to justify an option that a) cuts off the possibility of doing only _one_ thing b) mandates doing two steps is hilarious. In a Kafkaesque, my god, I'm a giant beetle everything still sucks kind of way. #wat -> @domenic > 2. All the standard combinators call .then not .chain. c) This isn't a reason against including .chain. d) .chain has one reasonably well known standard combinator on top of it: .then. e) Other "less" standard combinators will compose .chain, perhaps in ES.next. .chain'ists don't care about higher levels. They want someone to not wall off the damned ground floor entrance. Compose away, put whatever higher order stuff you want in, awesome, users will love it. But leave a non-composed primitive underneath, please, something that JUST does one thing: signals listeners with a value when it's ready, whatever that value happens to be. Using yet-higher order combinators to debase no-composition is #2. > 3. Including .chain requires always-wrapping resolve, observability >trumps optimizability. What does this effect beyond .resolve()? How much .resolve is out in the world? I'd love more on this. What I've got is from the meeting notes: "A resolve of a resolve does not create multiple levels of wrapping. Without chain this is not observable." -MM ".chain() requires over-wrapping/-unwrapping, without chain this is unobservable and therefore optimizable" -- says to reject chain -be What use cases are being debated here? I haven't seen STH or LH's proposals for chain/compromise, they are just short sentance fragments in the notes. It's hard to get a grasp on the magnitude/maturity of the optimization being discusssed here, this final point that swayed BE and YK. > There's really a 0 implicit in this: > > 0. Monadic vs. non-monadic is an exclusive or -- you can't "have it all". #3 is the only point I concede as being even possibly concrete, and is a question of optimizability, the extent of which hasn't been spoken to. The first are mere stylistic/ opinion-based assertions which cannot be contested. The compromises proposed having it all. It was literally closing minutes of ES6 when a new thing floated into sight and changed one person's mind. A second member attested that they'd rather not hold the show up, that they'd rather stamp this than old up ES6, and that all seems so ignoble, and it seems like .resolve() is such a tiny trivial barely used thing to make a "you can't have it all" case out of. Please help me, help others understand what #3 entails, what made it seem so so onerous. Yes, .resolve() was going to have to keep creating new wrappings: that was the point of chain! What else is there? TC39, ES6: please make the simpler uncomposed base case available. Un-finizale. Give users access to the base material. Allow people to engineer flow control: .then() insist on one brand of flow control, returns only a final done thing: please give the ability for promise chains to be used in not-yet-determined computation. MF --- Postscript: There seems to be some kind of notion floating about that "hey, you can just box your promises in an object and they won't resolve." This is only true for producers. If you use any existing promises based system, you will have no way what so ever to pull a chain out of it. .chain allows consumers to decide how to consume (it's an opt in thing), boxing has to be done producer side (up- front desgin). Please please please: let a promise return something that hasn't happened yet, so that _that_ promise can be reasoned about. --- Post-post-script: Async map(/monadic) really obfuscate what's being talked about to me. I respect that people can have conversations about it, and I'm sure you can understand the score marks as you talk back and forth over them, but I think it leaves a lot of people unable to grasp the issue itself: The ability to return a value "something from the the future" out of a promise, versus promises never ever being able to return anything but "done, here's the final thing." _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
