W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: [promises] Difficulties with using constructors and promises together

From: Mark S. Miller <erights@google.com>
Date: Thu, 20 Jun 2013 11:22:37 -0700
Message-ID: <CABHxS9iGXHLKtT7oerqh2CZTFE4DsLk6rN-wmVXexL=MSTF7GQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
Not sure I like this:

What about invoking the constructor function as a function, i.e., without
the "new". If it cannot create the object synchronously, then it can't
return the object synchronously, so there really is no constructor function
per se. So the name may as well just name a factory function which is just
called normally.

On Thu, Jun 20, 2013 at 10:20 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> When we're trying to construct an object, the right idiom is to use a
> constructor, rather than a factory function.  On the other hand, when
> we need to return something async, the right idiom is to use a
> promise.
> What about when we need to construct an object async?
> A few examples:
> * createImageBitmap()
> <
> http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#images
> >
> * TaskScheduler.add() <
> http://web-alarms.sysapps.org/#interface-taskscheduler>
> These two demonstrate both callback and Promise-based ways of dealing
> with this async object creation, and both are forced into using
> factory functions.
> Is this just what we'll have to do?  Whenever an object can only be
> created async, we have to add an "Interface.create()" function?  Or is
> there a better solution floating around somewhere that I can't see?
> (We've already rejected the solution of returning a promise from the
> constructor - that violates several implicit assumptions about
> constructor return values.)
> ~TJ

Received on Thursday, 20 June 2013 18:23:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC