domenic at domenicdenicola.com (2013-08-29T19:18:00.030Z)
On Wed, Aug 21, 2013 at 3:16 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote: > That's reasonable, but we should do it with a different function that > just promotes things into promises, Good idea. As a coercing function, a natural name is Promise.as(v1). Also, as a common coercer, brevity is a virtue.
On Wed, Aug 21, 2013 at 3:16 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote: > On Wed, Aug 21, 2013 at 1:57 PM, Mark S. Miller <erights at google.com> > wrote: > > Excellent excellent! It seems we are in agreement and clarity on all > > terminology issue, and on almost complete agreement on substantive > issues. > > The only remaining issue is whether either of the following expressions > > always return a fresh promise, and if they are exactly equivalent: > > > > a) Promise.resolve(v1) > > b) new Promise(r=>r.resolve(v1)) > > > > When v1 is a promise, > > x) I prefer that #a return v1 and #b return a fresh promise that adopts > v1. > > y) You prefer that both #a and #b return a fresh promise > > z) The fewest feasible allocations would have both return v1. > > w) I do not expect anyone will want #a to return a fresh promise and #b > to > > return v1. > > > > We both agree that if we settle on either #y or #z, then #a and #b are > > equivalent. Otherwise they are equivalent up to this issue. > > > > The reason I prefer that #b return a fresh promise is that it is > surprising > > for a "new" expression to return something other than a fresh object. > > I think it's super bizarre for a class static to act differently from > the trivial desugaring to the same-named instance method. (In this > case, it's not *quite* an instance method, but close enough. ^_^ It > would be an instance method if we weren't caring about capability > grants.) > > > The reason I prefer #a is that the primary use case for #a is coercion -- > > given possible promise v1, gimme a guaranteed genuine promise that > > designates the same (possibly eventual) non-promise. See calls to the Q() > > function at http://wiki.ecmascript.org/doku.php?id=strawman:concurrencyand > > http://es-lab.googlecode.com/svn/trunk/src/ses/contract/ (which > corresponds > > to http://research.google.com/pubs/pub40673.html ). These calls are > numerous > > and necessary, and sufficiently frequent that the extra transient > allocation > > in the typical case will be a noticeable cost. > > That's reasonable, but we should do it with a different function that > just promotes things into promises, Good idea. As a coercing function, a natural name is Promise.as(v1). Also, as a common coercer, brevity is a virtue. > or leave it to library code when > they need it. (We don't, for example, have such an operation for > Array/Map/Set, though I have used such an operation before.) > > ~TJ > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130821/838f374f/attachment-0001.html>