Specify the absense of resolve/fulfill/reject methods

[ForbesLindesay]

We should probably explicitly state somewhere that the promise object should only have methods to observe the promise, and not to mutate the state of the object. I know the spec aims to leave out how the promise is resolved, but we should probably still specify it happens elsewhere.
This might help reduce misunderstandings like #28

[domenic]

I disagree. You can have a perfectly valid, interoperable implementation that conflates promise and resolver. As long as the requirements of the spec are followed, this creates no problems.

[briancavalier]

I'm with @domenic on this one. Any robust implementation will almost certainly not conflate the two, but I don't feel we should prohibit it in this spec.

[lsmith]

+1

[briancavalier]

@lsmith couldn't tell if you meant +1 to specifying the absense of fulfill/reject as per @ForbesLindesay, or +1 to not specifying it as per @domenic and me. Can you clarify?

[lsmith]

I agree with you and @domenic.

[ForbesLindesay]

OK, I understand keeping the spec as open as possible, but since practically any robust solution will separate the two, perhaps we should have something in the notes section to recommend it. I think there's a lot of merit to adding some suggestions that are not requirements, so people new to promises don't fall into some of the more obvious seeming traps.

[briancavalier]

@lsmith thanks for clarifying. @ForbesLindesay hmmm, yes, that could be helpful. I'm all for helping devs "do the right thing"

How does everyone feel about something like that? For example, we could add a note ref to the end of paragraph 2, and the note content could provide some sort of nudge toward separating the resolver functionality.

Thoughts?

[domenic]

I think such guidance will be better as part of Resolvers/A+, which we should get cracking on after this weekend (i.e. after Node Knockout).

[ForbesLindesay]

Is the plan to actively specify what it means to be a resolver then?

[domenic]

Yes, maybe with some clarity on method names (e.g. clear up the confusingness that is deferred.resolve by naming it become or yield, see #5) and also specify things like resolution races etc.

[briancavalier]

@domenic I'm ok with seeing where it can fit in Resolvers/A+. The maybe we simply link to Resolves/A+ from paragraph 2. Since the majority are ok with not including it, I say we consider this issue closed, but leave it open for now as a reminder to create an issue for it in Resolvers/A+.

[domenic]

I say close the issue to minimize confusion and the outward appearance of "buginess." We're unlikely to forget this point.