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 wrote:
> > It allows you to reveal things, selectively, just as the revealing
> module pattern does. \
>
> The revealing module pattern is so named
> 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
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 wrote:
> Not to beat a dead horse but
>
> * No, it hasn't cau
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 hi
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
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 wan
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 wrote:
>
>
> Isiah Meadows wrote on 20. 7. 2018
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 capab
Fair enough. I was just hoping that the internal mechanism itself
could be exposed, since the spec already has to use it (as do
implementations 99% of the time). In case you're concerned about the
potential for abuse, I do have this:
1. It's different than what you'd get with `new Promise(...)` it
Reject and resolve static methods are not introducing a new ~maybe
dangerous~ pattern into the language, they are just isolating a factory for
a common use case (creating a promise wrapping a well know value at the
time of execution), deferreds add a whole lot of indirection in the table,
that migh
The use cases for "i want a resolved or rejected promise for a
value/reason" are much more numerous than for "i want a deferred", so yes,
I don't think a Deferred belongs in the language, and I think
Promise.resolve/reject absolutely clear that bar.
On Sat, Jul 21, 2018 at 11:19 AM, Isiah Meadows
> I think what Jordan means, it's that the deferred has it use case, but
> probably we don't want it in Javascript native library. There's a lot of
> mature libraries implementing deferred wrappers and most of them are Promise
> like compatible, and even if you cannot use libraries or don't want to
Just a heads up: that will throw, since the Promise constructor
executes its callback synchronously, and thus `this` isn't set up in
the callback until *after* it's called. You should probably rewrite it
the callback to store them locally and then set the properties and
call the factory after:
```
You are right, I didn't know you can use variables before calling the super
constructor (a Java thing).
So yeah, it's pretty easy to extend a Promise to externalize resolve and
reject
---
PS: Sorry about my last email last paragraph grammar, I'm yet getting used
to write long texts in English
Em
On Fri, Jul 20, 2018 at 12:15 PM Augusto Moura
wrote:
> Interesting enough, I got a really weird case (reads contraintuitive, I'm
> pretty sure the semantics of the error are right) extending the Promise
> class to exemplify a simple Deferred implementation, the code:
>
> ``` js
> class Deferred
I think what Jordan means, it's that the deferred has it use case, but
probably we don't want it in Javascript native library. There's a lot of
mature libraries implementing deferred wrappers and most of them are
Promise like compatible, and even if you cannot use libraries or don't want
to, you ca
So I run into this issue when waiting on multiple events I don't initiate.
What I do is create a subclass of promise that exposes these calls.
Not saying that's the ideal way to do it, but solvable in userland and
without modifying the base class.
On Thursday, July 19, 2018, Isiah Meadows wrote:
For code that high level, I don't even usually deal with promises in
the first place except when fetching data, saving data, and awaiting
renders and transforms (sometimes). Raw event handlers are good enough
for pretty much everything else, and when they aren't, you're almost
certainly dealing wit
First, I do get that not all uses of deferred-like objects really
merit the need for a deferred. For example, [here][1], I saved the
resolver and pulled the state out from the main closure to make the
state easier to follow. You could argue a deferred isn't really
necessary since I only care about
my use-case is the exact opposite. in integration-level javascript,
its impractical to have independent rejectors/error-handlers for
dozens of integrated-components. its much easier to debug/refactor
integration-code with a single, universal rejector/error-handler (all
it does is log the error-st
I've used this pattern exactly twice in the large-scale app I'm working on
now.
One of those I was able to eliminate after I thought harder about the
problem.
The other I eventually replaced with the following kind of pattern:
```
function createPromise(resolver, rejector) {
return new Promise((
I don't think the Deferred pattern is a good primitive to have in the
language, and it's a pretty trivial primitive to write yourself if you need
it.
On Thu, Jul 19, 2018 at 6:13 PM, Isiah Meadows
wrote:
> Sometimes, it's *very* convenient to have those `resolve`/`reject`
> functions as separate
22 matches
Mail list logo
