DISQUS

Bret · 1 year ago

The inside of the function doesn't have to look complex if you abstract out the gunk:

[blockcode]
requestProductDetails = asyncMemoize(function (id, k) {
ajax.get('/product/'+id, k);
});
[/blockcode]

Here's a definition of asyncMemoize. (My Javascript is rusty, so forgive any bad grammar.)

[blockcode]
function asyncMemoize (f) {
var cache = {};
return function (x, k) {
var v = cache[x];
if (v) {
setTimeout(function() { k(v); }, 1);
}
else {
f(x, function (v) {
cache[x] = v;
k(v);
});
}
}
}
[/blockcode]

(A better definition could use varargs, but whatever.)

I agree that a given function should always or never invoke the callback asynchronously. Not because I want to minimize code paths, but because that's part of the interface. Your first version of requestProductDetails essentially has undefined behavior!

I would go further and suggest a naming convention, either as part of the function name or the name of the continuation argument, that indicates that it's asynchronous. (I've been steeped in Objective-C for the last year, and I'm loving the Smalltalk-style descriptive method/argument naming.)

Chii · 1 year ago

while it is a good thing (tm) to make sure that code works the way the programmer expects - that the async callback gets executed after the next statement, one should remember that the reality of async is that you cannot guarentee order of execution, and thus, should instead modify the design of the program to not have to rely on the order of execution. There is no other way to fix this "problem".

oliver · 1 year ago

The modified function actually _does_ guarantee the order of execution: that the code that follows the call to @requestProductDetails@ will _always_ execute prior to the invocation of the continuation parameter.

Making each part of program not rely on the order of execution may seem like a good thing, but it increases the number of required test cases exponentially, if nothing else. Some indeterminacy is inherent in distributed processing; the rest can be determinized.

Paul Houle · 1 year ago

I've spent a lot of time in the last year working in GWT and Silverlight 2, both of which involve programming in a strictly typed OO language that uses XHR for communications: so you have the same issues with concurrency that you talk about in Javascript. I've been writing a series articles of patterns about how to write correct RIA's despite the fact that callbacks can run in a random order:

http://gen5.info/q/category/asynchronous-communications/

Bill Wilson · 1 year ago

I made a minor addition to the Memoize function to accept a variable number of arguments. I used this function to completely rewrite a series of AJAX calls. The results were quite nice. Thanks for the idea.


// Memoize function
// k must have a signature k(data,id,...);
//Additional arguments are passed to the program.
function asyncMemoize (f) {
var cache = {};
return function (x, k) {
var v = cache[x];
var args = Array.prototype.slice.call(arguments);
args[1] = x;
if (v) {
args[0] = v;
setTimeout(function() { k.apply(null,args); }, 10);
}
else {
f(x, function (v) {
cache[x] = v;
args[0] = v;
k.apply(null,args);
});
}
}
}