FWIW I have never heard of this terminology before either but in practice have used the pattern myself.
On Thu, Jul 26, 2018 at 12:15 AM, Bob Myers <r...@gol.com> wrote: > > It allows you to reveal things, selectively, just as the revealing > module pattern does. \ > > The revealing module pattern is so named precisely because it reveals (to > clients) certain aspects of the "module" in question. > Yes, it hides other aspects, but only by virtue of not revealing them. > If you want to support the terminology of "revealing constructor pattern", > could you please state *what* is being revealed, exactly, to *whom*? > When I call a promise constructor I get back one thing and one thing only, > which is a promise. > Is the notion that it is the promise which is being revealed? > In that sense, all APIs "reveal" their results. > If is the intent of using this term that the content of the executor is > being revealed to the coder when he views the code? > All code is revealed when it is viewed. > It would seem to me that to qualify for the name "revealing constructor > pattern" it ought to be revealing something. > > > (separately, the measure of "caught on" is not "there does not exist > someone who has not heard of it") > > This group is not a court of law with evidentiary rules. > That someone with a degree of interest in JS to the extent they are a > regular on the ML has never heard of it would seem to mean at least that it > has not caught on *widely*. > I myself had worked with and read about ES6 promises extensively before I > heard the term. > Perhaps in the future I can write things like "It might be argued by some > that there is some possibility that the evidence could conceivably be > interpreted as indicating that it may be the case that it has not caught on > widely"? > > In any case, "catching on", however you define it, would seem to require > more than a grand total of two Google results for "revealing constructor > pattern", one of which is by the person that invented it. > > Bob > > On Thu, Jul 26, 2018 at 3:13 AM Jordan Harband <ljh...@gmail.com> wrote: > >> 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 <r...@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 <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 > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
