Promise capability support

[Jordan Harband]

It allows you to reveal things, selectively, just as the revealing module
pattern does.

(separately, the measure of "caught on" is not "there does not exist
someone who has not heard of it")

On Wed, Jul 25, 2018 at 2:04 PM, Bob Myers <rtm at gol.com> wrote:

> Not to beat a dead horse but
>
> * No, it hasn't caught on, as evidenced by the recent poster who had never
> heard of it.
> * Yes, I know it's used to describe the Promise executor pattern.
> * "Revealing module pattern" reveals. The so-called "revealing constructor
> pattern" does not reveal anything. It hides. So the term is semantically
> incorrect from the beginning.
>
> Bob
>
> On Wed, Jul 25, 2018 at 10:55 PM Jordan Harband <ljharb at gmail.com> wrote:
>
>> It's already caught on - "revealing constructor pattern" is the pattern
>> that describes the Promise executor.
>>
>> The "revealing module" pattern is obsolete anyways, but it functions on
>> the same principle - using closures to reveal only explicit things instead
>> of everything.
>>
>> On Wed, Jul 25, 2018 at 10:01 AM, Bob Myers <rtm at gol.com> wrote:
>>
>>> Yes, I've encountered this "revealing constructor" terminology and find
>>> it confusing. I hope it doesn't catch on.
>>> A lot of people are likely to try to associate it with the "revealing
>>> module" pattern, with which it actually has nothing in common.
>>> It's a strange term because this pattern, if one wants to characterize
>>> it in terms of "revealing" things,
>>> is more about what is **not** being revealed (to the outside world), not
>>> what is being revealed.
>>>
>>> It's a useful pattern seen also in the observable constructor, and
>>> probably deserves to have a good name,
>>> but I can't come up with anything myself, other than maybe the
>>> suboptimal "callback-based constructor".
>>>
>>> Bob
>>>
>>> On Wed, Jul 25, 2018 at 6:45 PM Isiah Meadows <isiahmeadows at gmail.com>
>>> wrote:
>>>
>>>> Here's a quick overview of the "revealing constructor" pattern, if it
>>>> helps: https://blog.domenic.me/the-revealing-constructor-pattern/
>>>> -----
>>>>
>>>> Isiah Meadows
>>>> me at isiahmeadows.com
>>>> www.isiahmeadows.com
>>>>
>>>>
>>>> On Wed, Jul 25, 2018 at 7:05 AM, Herbert Vojčík <herby at mailbox.sk>
>>>> wrote:
>>>> >
>>>> >
>>>> > Isiah Meadows wrote on 20. 7. 2018 3:13:
>>>> >>
>>>> >> Sometimes, it's *very* convenient to have those `resolve`/`reject`
>>>> >> functions as separate functions. However, when logic gets complex
>>>> >> enough and you need to send them elsewhere, save a continuation,
>>>> etc.,
>>>> >> it'd be much more convenient to just have a capability object exposed
>>>> >> more directly rather than go through the overhead and boilerplate of
>>>> >> going through the constructor with all its callback stuff and
>>>> >> everything.
>>>> >>
>>>> >> It's surprisingly not as uncommon as you'd expect for me to do this:
>>>> >>
>>>> >> ```js
>>>> >> let resolve, reject
>>>> >> let promise = new Promise((res, rej) => {
>>>> >>      resolve = res
>>>> >>      reject = rej
>>>> >> })
>>>> >> ```
>>>> >>
>>>> >> But doing this repeatedly gets *old*, especially when you've had to
>>>> >> write it several dozen times already. And it comes up frequently when
>>>> >> you're writing lower-level async utilities that require saving
>>>> promise
>>>> >> state and resolving it in a way that's decoupled from the promise
>>>> >> itself.
>>>> >>
>>>> >> -----
>>>> >>
>>>> >> So here's what I propose:
>>>> >>
>>>> >> - `Promise.newCapability()` - This basically returns the result of
>>>> >> [this][1], just wrapped in a suitable object whose prototype is
>>>> >> %PromiseCapabilityPrototype% (internal, no direct constructor). It's
>>>> >> subclass-safe, so you can do it with subclasses as appropriate, too.
>>>> >> - `capability.resolve(value)` - This invokes the implicit resolver
>>>> >> created for it, spec'd as [[Resolve]].
>>>> >> - `capability.reject(value)` - This invokes the implicit rejector
>>>> >> created for it, spec'd as [[Reject]].
>>>> >> - `capability.promise` - This returns the newly created promise.
>>>> >>
>>>> >> Yes, this is effectively a deferred API, but revealing constructors
>>>> >> are a bit too rigid and wasteful for some use cases.
>>>> >
>>>> >
>>>> > Don't understand "revealing constructors". Can be done is userland in
>>>> a few
>>>> > lines. https://lolg.it/herby/deferred-lite
>>>> >
>>>> >> [1]: https://tc39.github.io/ecma262/#sec-newpromisecapability
>>>> >>
>>>> >> -----
>>>> >>
>>>> >> Isiah Meadows
>>>> >> me at isiahmeadows.com
>>>> >> www.isiahmeadows.com
>>>> >> _______________________________________________
>>>> >> es-discuss mailing list
>>>> >> es-discuss at mozilla.org
>>>> >> https://mail.mozilla.org/listinfo/es-discuss
>>>> >>
>>>> >
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180725/0d97034a/attachment-0001.html>