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 <isiahmead...@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 > m...@isiahmeadows.com > www.isiahmeadows.com > > > On Wed, Jul 25, 2018 at 7:05 AM, Herbert Vojčík <he...@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 > >> m...@isiahmeadows.com > >> www.isiahmeadows.com > >> _______________________________________________ > >> es-discuss mailing list > >> es-discuss@mozilla.org > >> https://mail.mozilla.org/listinfo/es-discuss > >> > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
