- From: Marcos Caceres <w3c@marcosc.com>
- Date: Mon, 18 Feb 2013 16:38:33 +0000
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Kenneth Rohde Christiansen <kenneth.r.christiansen@intel.com>, Mounir Lamouri <mounir@lamouri.fr>, public-sysapps@w3.org
On Monday, 18 February 2013 at 16:19, Jonas Sicking wrote:
> You should look at the DOMFuture API, which is currently the closest
> thing we have to a proposal for a standardized promise. It's just a
> DOMRequest with a .then function as well as some bikeshed naming
> issues ("value" instead of "result" etc).
>
> Keeping .result and .error separate is just good API design. Sure, we
> could stuff any errors into the .result property, but that makes it
> harder and more error prone for people to check if the promise
> succeeded or failed. I.e. you'd have to look at a separate .state or
> boolean .failed property to see if the .result contains a success or
> error value.
>
> There's definitely a lack of a Q.all function. That needs to be added.
> But it's not clear that that would go directly on the
> DOMRequest/DOMFuture interface.
>
> Of course, saying that "DOMRequest is just a promise without a .then
> function" is a bit of a simplification giving that most promise
> libraries are literally just a .then function. That doesn't change the
> fact that DOMRequest is a good stand-in until we have a standardized
> promise though.
Just trying to avoid lock-in when a potentially better solution exists - I just don't want to get to the point where people say "oh, we shipped… can't change it now. Sorry." If we are going to have stand-ins they should be clearly marked as such in the proposals.
> If you are eager to see a standardized promise I
> suggest you contribute to DOMFuture, which David Braunt has been
> doing, or otherwise bring a promise proposal to an appropriate W3C WG.
I'm keen to contribute to DOMFuture, which is why I dragged Alex and Anne into the discussion (though they've now vanished from the CC list) - so we can actually bring this to the right working groups, which right now mostly affects this one. It's also good to cover all angles of criticism that have been thrown at DOMRequest, and I appreciate you and Mounir addressing those.
--
Marcos Caceres
http://datadriven.com.au
Received on Monday, 18 February 2013 16:39:08 UTC