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 <ljh...@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 <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
