I do believe it meant to say 'cheap words and unreality'. Nothing to care about.
On Tue, Feb 4, 2014 at 11:04 PM, Brendan Eich <[email protected]> wrote: > [email protected] wrote: > >> > The existing promises library users would be faced with a porting >> problem >> > whose size is hard to estimate >> >> Naive go here; >> >> Promise.prototype.then= function(fn){ >> function recurse(val){ >> if(val.chain) >> val.chain(recurse) >> else >> fn(val) >> } >> return this.chain(recurse) >> } >> > > That's not how .then works in any existing library I know of. It's not how > .then works in Promises/A+ (http://promises-aplus.github.io/promises-spec/). > That is not going to interop with anything thenable. It introduces a new > chainable (duck-typed, no function value test even, .chain truthy property). > > There is no point in showing a trivial but incompatible layering of .then > on .chain. That's not the issue. > > Here is V8's .chain-based, self-hosted-in-V8's-JS-for-builtins-dialect, > Promise.prototype.then implementation: > > function PromiseThen(onResolve, onReject) { > onResolve = IS_UNDEFINED(onResolve) ? PromiseIdResolveHandler : > onResolve; > var that = this; > var constructor = this.constructor; > return this.chain( > function(x) { > x = PromiseCoerce(constructor, x); > return x === that ? onReject(MakeTypeError('promise_cyclic', [x])) : > IsPromise(x) ? x.then(onResolve, onReject) : onResolve(x); > }, > onReject > ); > } > > Notice the recursion is not via .chain, rather (and only if IsPromise(x), > a nominal type test) via .then. > > > I tend to believe there is for sure something real, and interesting under >> #3: that there was a real issue in implementation that drove ES6 at the >> very last hour away from .chain serving as the basis for .then. If you want >> something other than cheap words an unreality, >> > > (I have no idea what "cheap words an unreality" means here. Should I care?) > > > perhaps you'd color in some of those details. >> > > It's pretty simple. Adding .chain in addition to library-compatible .then > means Promise.resolve must always make a new promise, even for a promise > argument. Otherwise you can't compose resolve and chain to wrap once always > and unwrap once only, respectively. > > Drop .chain, use only .then, and resolve can cast instead of wrap, which > some promises libraries that lack chain indeed do today (an optimization, > #3 in your cited text, my point (3)). > > Having the two APIs together require what V8's self-hosted, > .chain-extended implementation does: always wrapping the argument x to > Promise.resolve in a new Promise. That's the problem I numbered (3). Clear? > > /be > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
