- From: Marcos Caceres <w3c@marcosc.com>
- Date: Thu, 14 Aug 2014 17:27:42 -0400
- To: "Mark S. Miller" <erights@google.com>
- Cc: Domenic Denicola <domenic@domenicdenicola.com>, Marcos Caceres <marcos@marcosc.com>, public-script-coord <public-script-coord@w3.org>, Dominique Hazael-Massieux <dom@w3.org>, Mounir Lamouri <mounir@lamouri.fr>
On August 14, 2014 at 5:15:48 PM, Mark S. Miller (erights@google.com) wrote: > I don't like just "resolve p" as by itself a phrase for your meaning, > because, in promise terminology, resolving a promise p does not imply that > p is fulfilled or even settled. Argh. You are right. I've been using it as meaning "resolve with X and assume it to be fulfill". > Resolving p to q, where q is an unsettled > promise, leaves p unsettled but still resolved. > > If, in the WebIDL world, you'd rather say "resolve p with void" rather than > "resolve p with undefined" or better "fulfill p with undefined", that would > not make the current WebIDL situation any worse, so fine. I think this makes sense. As the "WebIDL void" type conversion to JS would handle that. > It would merely > be part of WebIDL's continued presumption to describe non-JS APIs, with the > (mostly pointless) cost of making WebIDL a worse language for describing JS > APIs. > > But please not simply "resolve p". Despite its issues, hating on WebIDL doesn't help us (particularly at Moz), as we implement our (C++ and JS) bindings using it. The same with Blink and WebKit and their own IDL variants, IIUC. It's better to fix WebIDL (and the Promises Guide for Editors) as I don't know of any concrete plans to do away with using WebIDL in Browsers. I'm still hopeful that TC-39 will take it over and fix issues like the ones you point out.... but that's a subject for another place and thread :)
Received on Thursday, 14 August 2014 21:28:10 UTC