It depends more on how you are going to use them, right?
If your code looks like this:
var imageLoading = loadImage(url); // returns promise imageLoading.done(showImage); // imageLoading.done // imageLoading.error // imageLoading.then // imageLoading.success // imageLoading.fail // ... whatever your library supports
Then I could offer to call the promise something like a verb of current time ...
BUT if you create a library that depends on pending objects
// accepts a promise var showImage = function (promise) { promise.done(function (img) { /* ...... */ }); };
Then there is nothing particularly wrong with naming a variable as a noun if there is an understanding of which methods accept promises and which do not.
var image = loadImage(url);
Now your interfaces are really clean and you can write code that looks 100% procedural. ... buuuut, you need to know which functions / methods use promises and which objects use.
If you pass promises as callbacks inside object methods, you can happily name them promise or tweetLoading or dataParsing or something that makes sense in the context of this particular situation.
To determine showImage parameter I that I selected is flat, called promise , so if you are working on this function or you need to debug a chain of things, you can see, secondly, you looked at it that it received a promise object.
Norguard Jan 10 '13 at 21:53 2013-01-10 21:53
source share