On 9/10/14 11:25 AM, Eric Rescorla wrote: > On Wed, Sep 10, 2014 at 7:07 AM, Jan-Ivar Bruaroey <jib@mozilla.com > <mailto:jib@mozilla.com>> wrote: > > Except there's zero compatibility problems with overloading the > existing function as well, since it returns void, and callback > args can be made optional. > > > This seems like an especially bad idea. We've already had one Firefox > bug this > month that could have been averted by tighter argument checking. The firefox bug was caused by not having tests for a common use-case that still exists in the wild thanks to the spec changing - omitting callbacks to setRemoteDescription - People omit callbacks because a) it works, b) they don't see the need to check for failures at every turn, and c) because adding callbacks is laborious. Promises address these problems: omitted callbacks don't break propagation. The bug was not solved by tighter argument checking. Whether we overload the name or not doesn't change the size of the API surface, so I don't see that there'd be more bugs one way or the other. > I don't see the problem with defining a new API point that uses promises. > This also has the advantage that you could do it later. Sure, but then we're also stuck with callbacks forever. .: Jan-Ivar :.
Received on Wednesday, 10 September 2014 19:13:09 UTC