4 ms·
There's something that I'm missing here. Can anyone who is involved with this project clarify this example: function getFullName( id ){ return ajax
by drostie 11y ago
There's something that I'm missing here. Can anyone who is involved with this project clarify this example:
function getFullName( id ){
return ajax( "/user/" + id + "/name" ) + " " + ajax( "/user/" + id + "/lastname" )
}
I've read through the source and it mentions blocking etc. but I didn't see quite what I was looking for.
So here's the deal: at one point I was working on laziness library to treat promises as lazy values, and the problem that I ran into was that JS doesn't let you overload the operators `+`, `-`, etc. so that the API needs to export things like `Lazy.plus(p1, p2, p3)`. By itself that's not so bad -- it even makes everything look lispy in a strangely C syntax -- but it was sufficiently heavy that I kind of abandoned the project.
So from my understanding, the `+` can only work if the `ajax()` calls now block the global browser JS thread. Is that true? Does the above function even work synchronously, if I call it?
Of course, to actually use this function we have to use `Syncify.revert` which converts it back into a callback-based function. Does Syncify.revert have to somehow parse the function? How does it "stick its own context" into the function that it's calling without something complicated like dynamic variable scope? Or did you find a way to hack dynamic scope into JS?
- adrusi 11y agoI've only briefly looked through the source, so I'm not sure if they're doing this, but you can sort of intercept operators like `+` by implementing valueOf() on the object. When you perform a primitive operation on an object, the VM calls valueOf() on it to get a primitive value that it can handle. It does not tell you what operation caused valueOf to be called, nor does it let you influence the result (except by the primitive value you choose to return). I suspect that they're doing something else, and given the Syncify.parallel construct, I don't think they're blocking the whole thread.
- virulent 11y agoIt seems to depend on reactivity[1], hence it doesn't block. Here's an example: https://jsfiddle.net/k61y5sLo/2/ https://jsfiddle.net/k61y5sLo/2/ Pre-callback Evaluating getCallbackText() Post-callback callbackTest => cb("Alice") Evaluating getCallbackText() callbackTest => cb("Bob") Evaluating getCallbackText() Callback returned: Alice Bob https://github.com/aldonline/reactivity https://github.com/aldonline/reactivity
- zackmorris 11y agoThanks for the example. Just to clarify, it appears that you used syncify.revert(getCallbackText) to to create a callback from a synchronous function in order to log the final result. So it looks like Syncify.js evaluates the parent getCallbackText() function each time that one of its child callbackTest("Alice") or callbackTest("Bob") functions fire. Conceptually it replaces instantiations of callbackTest() with their return values. So on the final pass there are no more child functions to evaluate and it can return the final value. If this all sounds correct (and please correct me if I'm wrong) then the tradeoff is some re-run overhead in order to skip having to deal with promises or yield/generators.