The main argument against Promises in the past was churn to the existing API. I don't see any need to worry about that with new APIs (i.e. here). Regarding IDs, I agree with Stefan that it makes the most sense if the id attribute is on the sender, and therefore is unchanged by the replacement operation. On Wed, Sep 3, 2014 at 3:10 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 3 September 2014 14:31, Bernard Aboba <Bernard.Aboba@microsoft.com> > wrote: > > [BA] Would it be possible to handle this via a Promise? > > That would still be asynchronous, though it would work perfectly well. > And it would be my preference in fact, except for the fact that we > haven't moved to promises elsewhere. > > (On a side note, I think that we should be talking about retrofitting > Promises here. The cost is actually trivial and the advantages are > significant. They can be fitted to most methods that use callbacks > without disrupting existing users at all. I'll follow up on this > separately with a proposal, I think.) > >
Received on Wednesday, 3 September 2014 22:21:16 UTC