<div dir="ltr">It's already caught on - "revealing constructor pattern" is the pattern that describes the Promise executor.<div><br></div><div>The "revealing module" pattern is obsolete anyways, but it functions on the same principle - using closures to reveal only explicit things instead of everything.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 25, 2018 at 10:01 AM, Bob Myers <span dir="ltr"><<a href="mailto:rtm@gol.com" target="_blank">rtm@gol.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, I've encountered this "revealing constructor" terminology and find it confusing. I hope it doesn't catch on.<div>A lot of people are likely to try to associate it with the "revealing module" pattern, with which it actually has nothing in common.</div><div>It's a strange term because this pattern, if one wants to characterize it in terms of "revealing" things,</div><div>is more about what is **not** being revealed (to the outside world), not what is being revealed.</div><div><br></div><div>It's a useful pattern seen also in the observable constructor, and probably deserves to have a good name, </div><div>but I can't come up with anything myself, other than maybe the suboptimal "callback-based constructor".</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Bob</div></font></span></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 25, 2018 at 6:45 PM Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here's a quick overview of the "revealing constructor" pattern, if it<br>
helps: <a href="https://blog.domenic.me/the-revealing-constructor-pattern/" rel="noreferrer" target="_blank">https://blog.domenic.me/the-<wbr>revealing-constructor-pattern/</a><br>
-----<br>
<br>
Isiah Meadows<br>
<a href="mailto:me@isiahmeadows.com" target="_blank">me@isiahmeadows.com</a><br>
<a href="http://www.isiahmeadows.com" rel="noreferrer" target="_blank">www.isiahmeadows.com</a><br>
<br>
<br>
On Wed, Jul 25, 2018 at 7:05 AM, Herbert Vojčík <<a href="mailto:herby@mailbox.sk" target="_blank">herby@mailbox.sk</a>> wrote:<br>
><br>
><br>
> Isiah Meadows wrote on 20. 7. 2018 3:13:<br>
>><br>
>> Sometimes, it's *very* convenient to have those `resolve`/`reject`<br>
>> functions as separate functions. However, when logic gets complex<br>
>> enough and you need to send them elsewhere, save a continuation, etc.,<br>
>> it'd be much more convenient to just have a capability object exposed<br>
>> more directly rather than go through the overhead and boilerplate of<br>
>> going through the constructor with all its callback stuff and<br>
>> everything.<br>
>><br>
>> It's surprisingly not as uncommon as you'd expect for me to do this:<br>
>><br>
>> ```js<br>
>> let resolve, reject<br>
>> let promise = new Promise((res, rej) => {<br>
>>      resolve = res<br>
>>      reject = rej<br>
>> })<br>
>> ```<br>
>><br>
>> But doing this repeatedly gets *old*, especially when you've had to<br>
>> write it several dozen times already. And it comes up frequently when<br>
>> you're writing lower-level async utilities that require saving promise<br>
>> state and resolving it in a way that's decoupled from the promise<br>
>> itself.<br>
>><br>
>> -----<br>
>><br>
>> So here's what I propose:<br>
>><br>
>> - `Promise.newCapability()` - This basically returns the result of<br>
>> [this][1], just wrapped in a suitable object whose prototype is<br>
>> %PromiseCapabilityPrototype% (internal, no direct constructor). It's<br>
>> subclass-safe, so you can do it with subclasses as appropriate, too.<br>
>> - `capability.resolve(value)` - This invokes the implicit resolver<br>
>> created for it, spec'd as [[Resolve]].<br>
>> - `capability.reject(value)` - This invokes the implicit rejector<br>
>> created for it, spec'd as [[Reject]].<br>
>> - `capability.promise` - This returns the newly created promise.<br>
>><br>
>> Yes, this is effectively a deferred API, but revealing constructors<br>
>> are a bit too rigid and wasteful for some use cases.<br>
><br>
><br>
> Don't understand "revealing constructors". Can be done is userland in a few<br>
> lines. <a href="https://lolg.it/herby/deferred-lite" rel="noreferrer" target="_blank">https://lolg.it/herby/<wbr>deferred-lite</a><br>
><br>
>> [1]: <a href="https://tc39.github.io/ecma262/#sec-newpromisecapability" rel="noreferrer" target="_blank">https://tc39.github.io/<wbr>ecma262/#sec-<wbr>newpromisecapability</a><br>
>><br>
>> -----<br>
>><br>
>> Isiah Meadows<br>
>> <a href="mailto:me@isiahmeadows.com" target="_blank">me@isiahmeadows.com</a><br>
>> <a href="http://www.isiahmeadows.com" rel="noreferrer" target="_blank">www.isiahmeadows.com</a><br>
>> ______________________________<wbr>_________________<br>
>> es-discuss mailing list<br>
>> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
>> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
>><br>
><br>
______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
</blockquote></div>
</div></div><br>______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>