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 <r...@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 <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 > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
