- From: Justin Novosad <junov@google.com>
- Date: Wed, 17 Jul 2013 19:21:53 -0400
- To: Ian Hickson <ian@hixie.ch>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, WHAT Working Group <whatwg@whatwg.org>
On Wed, Jul 17, 2013 at 6:54 PM, Ian Hickson <ian@hixie.ch> wrote: > On Thu, 18 Jul 2013, Silvia Pfeiffer wrote: > > At the same time, I think we should follow a clear pattern for > > introducing a Promise based API, which the .create() approach would > > provide. > > I don't understand what that means. > I think the concern is about the case where we end up with legacy callback Factory methods that co-exist new with Promise-based flavors of the factory methods. There's no technical obstacle to having the two co-exist with the same name, it's just an overload. I guess the concern is more about code readability. Is that it? > I guess I'm asking for JS dev input here... > > Promises are just regular callbacks, with the synchronisation done by the > browser (or shim library) rather than by author code. I don't really > understand the problem here. > Yes. In the case of createImageBitmap the resolver would be built-in to the promise by the browser, so there is nothing to set-up. Devs who are not ready to fully embrace Promises can use this API the same way they would a callback API, but with a slightly different syntax: Not too scary IMHO > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Received on Wednesday, 17 July 2013 23:22:20 UTC