W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

Re: Promise<void> or Promise<undefined>?, was Re: RfC: pre-LC version of Screen Orientation; deadline August 18

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>
Message-ID: <etPan.53ed29ce.238e1f29.e7a@Marcoss-MacBook-Pro.local>

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

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