rtm at gol.com (2018-07-26T11:59:00.657Z)
> 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
> 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 <ljharb at 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 <rtm at 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 <ljharb at 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 <rtm at 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 <isiahmeadows at 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 >>>>> me at isiahmeadows.com >>>>> www.isiahmeadows.com >>>>> >>>>> >>>>> On Wed, Jul 25, 2018 at 7:05 AM, Herbert Vojčík <herby at 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 >>>>> >> me at isiahmeadows.com >>>>> >> www.isiahmeadows.com >>>>> >> _______________________________________________ >>>>> >> es-discuss mailing list >>>>> >> es-discuss at mozilla.org >>>>> >> https://mail.mozilla.org/listinfo/es-discuss >>>>> >> >>>>> > >>>>> _______________________________________________ >>>>> es-discuss mailing list >>>>> es-discuss at mozilla.org >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> es-discuss at mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180726/8a54305c/attachment.html>