4 ms·

Sorry, should have clarified on 2. As an expansion of one of the examples given: loadAndPrintFile: (contents) { if (!contents) { fs.readFil

Sorry, should have clarified on 2. As an expansion of one of the examples given: loadAndPrintFile: (contents) { if (!contents) { fs.readFile() -> (error!, contents) } console.log(contents); } i.e., expected behavior would be as if readFile was not an async function. I'm asking because I built something similar (though it only worked with promises, not general async functions), and I'm curious to compare approaches :-) - mine is a sweet.js macro: http://pastie.org/9410315 http://pastie.org/9410315 (uses https://github.com/petkaantonov/bluebird https://github.com/petkaantonov/bluebird and https://github.com/BranchMetrics/promise-accum https://github.com/BranchMetrics/promise-accum). The basic syntax would be: task { item1 <- LoadItem(1); item2 <- LoadItem(item1.foreign_key); ret <- DoSomethingWithItems(item1, item2); }

chmod775 12y ago
The JavaScript result of your example looks like this: (again, beautified because DesignToJS crams everything in one line to preserve the line numbers of your actual code): function loadAndPrintFile(contents) { if (!contents) { fs.readFile(function(error, contents){ if(error !== null && error !== undefined){ return error; } }); } console.log(contents); } If you omit the function body, it will only expand to the end of the current logical 'context' (or whatever it's called) I'd suggest writing it like this in DesignToJS: loadAndPrintFile: (contents! console.log) { fs.readFile() -> (error!, contents! console.log) } Result looks like this: function loadAndPrintFile(contents) { if(contents !== null && contents !== undefined){ return console.log(contents); } fs.readFile(function(error, contents){ if(error !== null && error !== undefined){ return error; } if(contents !== null && contents !== undefined){ return console.log(contents); } }); } Edit: I just submitted a patch that avoids unnecessary binding of 'this' if 'this' is not actually used.
- dmitrig01 12y ago
  Ah, very interesting use of the ! operator.
- asynchrony 12y ago
  In Javascript (contents !== null && contents !== undefined) is equivalent to (contents != null).
  - chmod775 12y ago
    Now that is good to know, thank you. I'll make that change asap.

chmod775 12y ago

The JavaScript result of your example looks like this: (again, beautified because DesignToJS crams everything in one line to preserve the line numbers of your actual code): function loadAndPrintFile(contents) { if (!contents) { fs.readFile(function(error, contents){ if(error !== null && error !== undefined){ return error; } }); } console.log(contents); } If you omit the function body, it will only expand to the end of the current logical 'context' (or whatever it's called) I'd suggest writing it like this in DesignToJS: loadAndPrintFile: (contents! console.log) { fs.readFile() -> (error!, contents! console.log) } Result looks like this: function loadAndPrintFile(contents) { if(contents !== null && contents !== undefined){ return console.log(contents); } fs.readFile(function(error, contents){ if(error !== null && error !== undefined){ return error; } if(contents !== null && contents !== undefined){ return console.log(contents); } }); } Edit: I just submitted a patch that avoids unnecessary binding of 'this' if 'this' is not actually used.

dmitrig01 12y ago
Ah, very interesting use of the ! operator.
asynchrony 12y ago
In Javascript (contents !== null && contents !== undefined) is equivalent to (contents != null).
- chmod775 12y ago
  Now that is good to know, thank you. I'll make that change asap.