domenic at domenicdenicola.com (2013-08-05T20:13:24.444Z)
On Thu, Aug 1, 2013 at 10:00 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote: > On Thu, Aug 1, 2013 at 9:09 AM, Anne van Kesteren <annevk at annevk.nl> > > Having done that. I wonder if we could leave the monad part out for > > now. As Mark pointed out in the other thread it causes a bunch of > > headaches to get that correct, and since we already decided (I > > believe) to not break with existing practice we could ship the subset > > that is that and figure out the superset-promise-that-works-for-monads > > later. That might also give us some insight into how many people will > > want to wrap promises to make the monad-suitable. > > Let's not reopen this, please. There are three questions here, which need to be settled in roughly this chronological order: 1. What should tc39 do quickly, to unblock the DOM's need for promises and avoid a design fork? 2. What should DOM do quickly the tc39's quick output? 3. Once #1 and #2 are settled, what should tc39 do for es7? For #1 I agree with Tab. We should not reopen this issue, but should rather proceed to settle the AP2ish design quickly. Otherwise we won't settle anything quickly and DOM will go their own way. For #2, since whatever DOM does quickly becomes a compat constraint on all future decisions, DOM should take the minimum subset of #1 which actually meets their short term needs. I leave it to those who understand those needs to argue about what these are. For #3, we will hopefully stay upwards compat with both #1 and #2. But compat with #2 will be more pressing, as that will have been massively deployed as part of the browser. > The way I've outlined things means > that then()-based stuff works compatibly with the existing spec, so > that's not a concern. We've already had long threads about why nested > promises are useful (namely, that "promise" in practice isn't a single > type - you have multiple types of promises from different promise > sources, and don't always want to smash them together). > These have been long threads so I won't rehash them either. However, I will point out that these long threads also explain why nested promises won't be useful.
On Thu, Aug 1, 2013 at 10:00 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote: > On Thu, Aug 1, 2013 at 9:09 AM, Anne van Kesteren <annevk at annevk.nl> > wrote: > > On Thu, Aug 1, 2013 at 5:07 PM, Anne van Kesteren <annevk at annevk.nl> > wrote: > >> I basically took Tab's email and rewrote the terminology. I omitted > >> the issues for brevity. Hopefully this helps. > > Sorry, I was waiting until Mark and Domenic had finished up their > terminology discussion before I did a third rewrite. > > > Having done that. I wonder if we could leave the monad part out for > > now. As Mark pointed out in the other thread it causes a bunch of > > headaches to get that correct, and since we already decided (I > > believe) to not break with existing practice we could ship the subset > > that is that and figure out the superset-promise-that-works-for-monads > > later. That might also give us some insight into how many people will > > want to wrap promises to make the monad-suitable. > > Let's not reopen this, please. There are three questions here, which need to be settled in roughly this chronological order: 1) What should tc39 do quickly, to unblock the DOM's need for promises and avoid a design fork? 2) What should DOM do quickly the tc39's quick output? 3) Once #1 and #2 are settled, what should tc39 do for es7? For #1 I agree with Tab. We should not reopen this issue, but should rather proceed to settle the AP2ish design quickly. Otherwise we won't settle anything quickly and DOM will go their own way. For #2, since whatever DOM does quickly becomes a compat constraint on all future decisions, DOM should take the minimum subset of #1 which actually meets their short term needs. I leave it to those who understand those needs to argue about what these are. For #3, we will hopefully stay upwards compat with both #1 and #2. But compat with #2 will be more pressing, as that will have been massively deployed as part of the browser. > The way I've outlined things means > that then()-based stuff works compatibly with the existing spec, so > that's not a concern. We've already had long threads about why nested > promises are useful (namely, that "promise" in practice isn't a single > type - you have multiple types of promises from different promise > sources, and don't always want to smash them together). > These have been long threads so I won't rehash them either. However, I will point out that these long threads also explain why nested promises won't be useful. > > ~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/a37c6e98/attachment.html>