<div dir="ltr">On Wed, Jun 5, 2013 at 3:37 AM, Anne van Kesteren <span dir="ltr"><<a href="mailto:annevk@annevk.nl" target="_blank">annevk@annevk.nl</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Jun 4, 2013 at 4:32 PM, Mark S. Miller <<a href="mailto:erights@google.com">erights@google.com</a>> wrote:<br>

> Given this direction, I think the one operation that serves as both<br>
> Promise.resolve and Promise.fulfill should be the previously suggested<br>
> Promise.of.<br>
<br>
</div>I think you still want Promise.resolve because it makes sense with<br>
Promise.reject and the instance methods on PromiseResolver. Promise.of<br>
would be a good alias to have.<br></blockquote><div><br></div><div style>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</div>
<div style><br></div><div style>    Q(p).then(...)</div><div style><br></div><div style>or more generally,</div><div style><br></div><div style>    ....Q(p)....</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>For the same reason, promiseResolver.resolve also needs to do one level of flattening.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
<br>
> I am always worried though when people use the term "unwrapping" as I<br>
> don't know what they mean. Does this mean flattening, assimilating, both, or<br>
> something else? What I mean here is to so one level of flattening. As for<br>
> whether .then should also do one level of assimilation if it sees a<br>
> non-promise thenable, I could go either way, but prefer that it should not.<br>
> The promise-cross-thenable case should be sufficiently rare that the cost of<br>
> the extra bookkeeping should be negligible.<br>
<br>
</div>Sorry for the confusion. I thought you guys had already settled on<br>
accepting what the DOM standard currently defines (no branding checks<br>
of any kind, just use a callable then property, if any). If that's not<br>
the case, writing out the desired behavior for then()/flatMap() here<br>
would help.<br></blockquote><div><br></div><div style>No. We still need the brand check. I will write the desired behavior soon -- hopefully tonight.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
<br>
--<br>
<a href="http://annevankesteren.nl/" target="_blank">http://annevankesteren.nl/</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>    Cheers,<br>    --MarkM
</div></div>