Terminology: overuse of "resolv*"

[allenwb]

The formal parameter of the Promise constructor is called "resolver" and it's value is a a function with a two formal formal parameters resolve and reject. The over use of resolve-rooted words make it difficult to write a comprehensible prose description of the Promise constructor.

Is resolver really the best name for the constructor's parameter? Isn't it the job of that function to initiate the deferred/async computation. Could be call it the "initiator"?

[domenic]

"Resolver" is the traditional name (via a discussion @wycats and I had, actually), but I see your point. Since it doesn't impact much, I don't have a problem changing it if others agree. Tagging in @promises-aplus people here.

To explain why "resolver" is traditional: it's the function that's given the ability to resolve the promise, i.e. it is the thing that resolves.

[erights]

I have also always disliked "resolver" as the name for this function. To me, informally, the "resolver" remains the short noun for talking about "the resolve function". I have not previously raised it because I don't have a suggested alternative. "initiator" is not great, but it is better than the status quo.

[allenwb]

Since it both initiates and resolves we might consider "manager" but that's one of those generic words that is best avoided. I think I'm going to name the parameter "initiator" unless somebody thinks of something better.

[wycats]

I don't think initiator makes sense here (what does it mean?). The name "resolver" isn't great, but it's better than anything else I've heard.

[erights]

Naming rationales:

In favor of using "resolver" as the noun for the resolve function: * It provides the power to resolve (the corresponding promise)

In favor of using "resolver" as the noun for the function provided to the constructor * It has the power (and responsibility) to resolve...

I can see it either way. And I don't like initiator. Sigh.

[allenwb]

@wycats the argument to the Promise construction is the function that "initiates" the computation whose value the promise will eventually represent, eg the first line of the passed function below "initiates" an async read of a file:

new Promise((resolve, reject) => {
    FS.readFile("foo.txt", "utf-8", (error, text) => {
          if (error) {reject(new Error(error))
          } else {resolve(text)}
     );
});

the function that is passed is no more a "revolve" than it is a "rejector" and as I said at the start of this thread it is almost impossible to talk about a function implicitly name named "resolver" that has an argument named "resolve".

The challenge isn't to defend the name "resolver", it is to come up with something better than 'initiator".

[domenic]

the function that is passed is no more a "revolve" than it is a "rejector"

Although this is no longer true at the level of the spec, rejecting is a subset of resolving, from the user's point of view. reject(r) is syntactic sugar for resolve(Promise.reject(r)), in that the user-observable effects are indistinguishable.

Thus the reason all existing libraries are calling it "resolver."

[domenic]

Folding this issue into #91. For those watching from at home, @allenwb seem to have settled on "executor." I guess we'll stick with that since he seems to care a lot and even though most other parties seem to prefer "resolver," I don't think this is an issue that evokes passionate argument for us.