- From: Mark S. Miller <erights@google.com>
- Date: Thu, 20 Jun 2013 11:22:37 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
- Message-ID: <CABHxS9iGXHLKtT7oerqh2CZTFE4DsLk6rN-wmVXexL=MSTF7GQ@mail.gmail.com>
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 > > -- Cheers, --MarkM
Received on Thursday, 20 June 2013 18:23:04 UTC