Re: async decision making (was Re: Promise.cast and Promise.resolve)

2014-02-07 Thread Andreas Rossberg
On 5 February 2014 12:10, Alex Russell slightly...@google.com wrote: On Wed, Feb 5, 2014 at 12:00 PM, Brendan Eich bren...@mozilla.com wrote: I'd rather we keep separate and conflict-prone APIs in separate objects, though. I'd rather we acknowledge that Promises are a library de-facto

async decision making (was Re: Promise.cast and Promise.resolve)

2014-02-05 Thread Edward O'Connor
Hi, Mark wrote: Unfortunately, just as Yehuda was not there in September and did not agree to the consensus then, Andreas was not there on Thursday of January and (above in this thread) does not agree to that consensus. This indicates a different failure mode we should be concerned about.

Re: async decision making (was Re: Promise.cast and Promise.resolve)

2014-02-05 Thread Brendan Eich
Edward O'Connor wrote: Perhaps TC39 should consider adopting a similar policy. Policy, schmolicy :-P. (Presumably clocks with deadlines are required; consensus could break afterwards, in spite of the formal rules.) Let's let our hair down a bit and get real here. We did not declare

Re: async decision making (was Re: Promise.cast and Promise.resolve)

2014-02-05 Thread Alex Russell
On Wed, Feb 5, 2014 at 12:00 PM, Brendan Eich bren...@mozilla.com wrote: Edward O'Connor wrote: Perhaps TC39 should consider adopting a similar policy. Policy, schmolicy :-P. (Presumably clocks with deadlines are required; consensus could break afterwards, in spite of the formal rules.)

Re: async decision making (was Re: Promise.cast and Promise.resolve)

2014-02-05 Thread Brendan Eich
Alex Russell wrote: I'd rather we keep separate and conflict-prone APIs in separate objects, though. I'd rather we acknowledge that Promises are a library de-facto quasi-standard we are trying to codify, not green-field work where we can start over or do both. Excited to hear