domenic at domenicdenicola.com (2013-08-05T20:08:46.243Z)
Between Tab's answer and mine, we see the two issues one might mean by "branding". Anne's clarifying summary at https://mail.mozilla.org/pipermail/es-discuss/2013-August/032465.html speaks only in terms of "promise-likes". One of the things we need to settle is whether there is one predicate that applies to all the places in this summary that says "if ... promise-like". IMO we need to distinct tests -- * isPromise for whether p is a promise and * isThenable for whether p is thenable. I would have the output-side tests for both .flatMap and .then be isPromise. I would also have the input side test for .then use isThenable. .flatMap has no input-side test, which is its point. A somewhat separable question is what these two tests are testing. The first hard reason why we must at least have an isPromise test on the output side of .then is that the promise already returned by .then must adopt this output promise without calling its .then method. Otherwise we lose support for lazy evaluation and for promise pipelining. If the output side of .then is a non-promise thenable, it is a separate question whether it should be "adopted" by calling its .then method or whether it should be accepted. IMO it should be accepted. The isThenable test indicates something ugly is going on -- assimilation. With this AP2 based design, we can isolate this ugliness to the input side of .then. The second reason why the two tests need to be separate is that the output side of .flatMap cannot adopt simply by calling the output's .then method, because otherwise you'd often get exactly the recursive unwrapping that .flatMap is trying to avoid. In order to avoid this, it must test whether there is anything it can do to adopt other than calling .then.
Between Tab's answer and mine, we see the two issues one might mean by "branding". Anne's clarifying summary at https://mail.mozilla.org/pipermail/es-discuss/2013-August/032465.htmlspeaks only in terms of "promise-likes". One of the things we need to settle is whether there is one predicate that applies to all the places in this summary that says "if ... promise-like". IMO we need to distinct tests -- * isPromise for whether p is a promise and * isThenable for whether p is thenable. I would have the output-side tests for both .flatMap and .then be isPromise. I would also have the input side test for .then use isThenable. .flatMap has no input-side test, which is its point. A somewhat separable question is what these two tests are testing. The first hard reason why we must at least have an isPromise test on the output side of .then is that the promise already returned by .then must adopt this output promise without calling its .then method. Otherwise we lose support for lazy evaluation and for promise pipelining. If the output side of .then is a non-promise thenable, it is a separate question whether it should be "adopted" by calling its .then method or whether it should be accepted. IMO it should be accepted. The isThenable test indicates something ugly is going on -- assimilation. With this AP2 based design, we can isolate this ugliness to the input side of .then. The second reason why the two tests need to be separate is that the output side of .flatMap cannot adopt simply by calling the output's .then method, because otherwise you'd often get exactly the recursive unwrapping that .flatMap is trying to avoid. In order to avoid this, it must test whether there is anything it can do to adopt other than calling .then. On Thu, Aug 1, 2013 at 10:43 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote: > On Thu, Aug 1, 2013 at 10:33 AM, Juan Ignacio Dopazo > <dopazo.juan at gmail.com> wrote: > > If then() deep flattens, flatMap() only flattens one level and promises > > assimilate thenables, is branding really necessary? > > The concept of "thenable" *is* branding. It's just branding with a > short, simple string property ("then"), rather than branding with a > hard-to-collide string (like __promiseBrand__ or something) or a > symbol. > > ~TJ > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130801/b8495112/attachment.html>