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: Mark S. Miller <erights@google.com>
Date: Thu, 14 Aug 2014 14:15:48 -0700
Message-ID: <CABHxS9jRbao403Yi3KoqXyY5_8PjDLZk9ahoXWvmc+asvtdXGQ@mail.gmail.com>
To: Marcos Caceres <w3c@marcosc.com>
Cc: public-script-coord <public-script-coord@w3.org>, Marcos Caceres <marcos@marcosc.com>, Domenic Denicola <domenic@domenicdenicola.com>, Mounir Lamouri <mounir@lamouri.fr>, Dominique Hazael-Massieux <dom@w3.org>
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. 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. 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".




On Thu, Aug 14, 2014 at 2:06 PM, Marcos Caceres <w3c@marcosc.com> wrote:

>
>
> On August 14, 2014 at 5:01:24 PM, Marcos Caceres (marcos@marcosc.com)
> wrote:
> > > I don't feel strongly about it either. To me, it's probably more
> > clear to just say "resolve p", because it doesn't imply that one
> > is passing an actual thing to the resolver (where "resolve p"*
>
> * Sorry, here I meant "resolve p with `undefined`"
>
> > looks like, in a JS implementation of WebIDL: `resolver(undefined)`
> > even if equivalent to just calling `resolver()`). I guess generally,
> > unless one is resolving with something, maybe it's best to just
> > exclude the "" altogether, as it's should be implied to
> > be void.
>
>
>


-- 
    Cheers,
    --MarkM
Received on Thursday, 14 August 2014 21:16:15 UTC

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