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

[Silvia Pfeiffer]

On 18 Jul 2013 07:57, "Ian Hickson" <ian at 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(),
etc)
> >
> > 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...

Silvia.