On Wed, Jun 5, 2013 at 3:37 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Tue, Jun 4, 2013 at 4:32 PM, Mark S. Miller <erights@google.com> wrote:
> > Given this direction, I think the one operation that serves as both
> > Promise.resolve and Promise.fulfill should be the previously suggested
> > Promise.of.
>
> I think you still want Promise.resolve because it makes sense with
> Promise.reject and the instance methods on PromiseResolver. Promise.of
> would be a good alias to have.
>
Wow. In writing a response to this I ended up reversing myself. I realize
that I no longer agree that one operation serves both purposes. I agree
with Sam that Promise.resolve no longer needs to do recursive flattening or
assimilation. But unlike Promise.fulfill, it does need to do one level of
flattening. The reason is the same as the reason that .then (and presumably
.chain whatever it is called) needs to do one level of flattening
(.flatMap-like) on its result -- the allocation cost of doing otherwise is
prohibitive. The common defensive promise programming pattern is
Q(p).then(...)
or more generally,
....Q(p)....
when p is received from a possibly untrusted source, such as any client of
a defensively consistent abstraction, to ensure one is operating on a
genuine promise and protected from plan interference attacks. If we have
both Promise.resolve and Promise.fulfill, then Q as a function would be
equivalent to Promise.resolve and all would be happy. But if we have only
Promise.fulfill (whether spelled Q or Promise.of or whatever) and it is
used instead in such patterns, then, because of the presence of .chain, it
would always have to allocate a new promise even when p is already a
promise.
For the same reason, promiseResolver.resolve also needs to do one level of
flattening.
>
>
> > I am always worried though when people use the term "unwrapping" as I
> > don't know what they mean. Does this mean flattening, assimilating,
> both, or
> > something else? What I mean here is to so one level of flattening. As for
> > whether .then should also do one level of assimilation if it sees a
> > non-promise thenable, I could go either way, but prefer that it should
> not.
> > The promise-cross-thenable case should be sufficiently rare that the
> cost of
> > the extra bookkeeping should be negligible.
>
> Sorry for the confusion. I thought you guys had already settled on
> accepting what the DOM standard currently defines (no branding checks
> of any kind, just use a callable then property, if any). If that's not
> the case, writing out the desired behavior for then()/flatMap() here
> would help.
>
No. We still need the brand check. I will write the desired behavior soon
-- hopefully tonight.
>
>
> --
> http://annevankesteren.nl/
>
--
Cheers,
--MarkM