W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2013

Re: [whatwg] Proposal: createImageBitmap should return a "Promise" instead of using a callback

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 18 Jul 2013 08:12:00 +1000
Message-ID: <CAHp8n2k9+hQC29U18K33K=4M50TiTXZ1acCiaKoF05aghp6MHQ@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Justin Novosad <junov@google.com>, Rick Waldron <waldron.rick@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, WHAT Working Group <whatwg@whatwg.org>
On 18 Jul 2013 07:57, "Ian Hickson" <ian@hixie.ch> wrote:
> On Thu, 18 Jul 2013, Silvia Pfeiffer wrote:
> > >
> > > There are basically two styles:
> > >
> > >  - constructors (new Date(), new Function(), etc)
> > >  - factory methods on the "parent" object (document.createElement(),
> > >    implementation.createDocument(), context.createLinearGradient(),
> >
> > Do we have a strategy for moving to Promises for all sync factory
> > methods across the API?
> Using Promises vs the issue of the factory method names are two orthogonal
> issues.
> We can't change old APIs to use Promises (and indeed in most cases they're
> not needed, e.g. all those I cite above). If you don't need a promise, you
> should really just use a constructor.

Sorry I meant it for the case of *async* factory methods - i.e. method like
createImageBitmap() . we will of course continue to need constructors.

> > I'm asking because it seems like a big change of programming pattern and
> > not everyone may be ready to move on from the old one yet (read: this is
> > next generation technology), so would it be better to keep both
> > interfaces around for a while?
> We can never remove functionality. I don't think it's ever good to have
> duplicate functionality. But in this case I think this is a non-issue.

In this case you did remove the non-promise based approach - presumably
because it has not been implemented in browsers yet, which is fair enough
for browsers. However, for JS developers it means that if they want to use
this function, they now have to move to introduce a Promise model in their
libraries. I'm just dubious whether they are ready for that yet (in fact, I
have heard that devs are not ready yet).

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 guess I'm asking for JS dev input here...

Received on Wednesday, 17 July 2013 22:12:23 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:03 UTC