- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 18 Jul 2013 00:00:08 +0000 (UTC)
- To: Justin Novosad <junov@google.com>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, WHAT Working Group <whatwg@whatwg.org>
On Wed, 17 Jul 2013, Justin Novosad wrote: > 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 I don't understand what methods we're talking about here. Can we be more concrete? I am very much in favour of not having redundant APIs, not having lots of different kinds of APIs. But I'm not aware of this problem existing here. We have constructors and synchronous factory methods, have had for over a decade, and we're slowly adding constructors where it makes sense and not adding new synchronous factory methods. But in the case of ImageData, we need an asynchronous factory. This is unusual in the Web; mostly we have instead returned incomplete objects. In this case, the whole point of the API is to avoid this. This means we need a callback mechanism; Promises are a good, non-invasive way to do this. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 18 July 2013 00:00:34 UTC