bigeasy
commented
13 years ago I'd begun to develop with Async Eco, took a break, and now I'm back. This code seems to be stabilizing. I'll be working with it more in the new few weeks.
In the mean time, here's my current development. I've added tests for the async code. Current users of Eco are not effected by these changes. Their code will run as it always has. All existing tests pass. Asynchronicity is enabled with a compiler flag. The resulting template expects a callback as second argument. The callback receives an idomatic (error, output) as its result.
I had to change the scanner slightly to report the block nature of a code scan to the beginCode method of the preprocessor. This effected only the scanner and not the processors. Details can be found in d60bbb3.
I made a slight change to the indent helper seen in d60bbb3 to remove the indent from the first line, making it easier to add optional blocks to the JavaScript function building heredoc.
Note that all existing compiler test fixtures are unchanged. The compiler output for non-async code after this patch is applyed is identical.
Probably need to patch the documentation as well. Seeking feedback on progress so far. Please checkout and run tests and tell me what you think.
First, notes from the discussion on the CoffeeScript mailing list, taken from discussion earlier today on IRC.
I've decided to make async a compiler option. If the option is all, all helper blocks are called asynchronously. If it is off, the function is identical to the current Eco generated functions. This is because the helper author and the compiler invoker are almost certainly the same person, and they will know if async is necessary or not.
When async is on, the generated function takes a callback. If it is off, the generated function returns its result as it always has.
This leads to the following programming problems with async Eco:
I've come to the following decisions regarding the questions at the end of that post:
Maybe there's a way for the helper to say that it is async, instead of having to remember that in the code? (Too much complexity defeats the use case.) ~ Currently, I'm tucking an exclamation point into the directive to indicate that the call should be async. This is fiddly. The async implementation is supposed to be transparent to the template author. When I'm writing templates, I don't want to think about concurrency. The use case given for async Eco is a template system for people used to writing themes with a a template language. Telling them they forgot the
!will only lead to a painful attempt to explain to them what it is for. Thus, I've decided that there will be no extensions to the Eco directives.This decision addresses the other question as well.
Async blocks in code and no callback? You get "[ Function ]" in your blocks. Could easily detect this condition, but how to report the error? Exception? Or let it slide? ~ Instead of async being a property that is applied per block helper, it is applied to all helper blocks in a template using a complier option. This means that if the option is not present, there is no effect at all on the existing Eco templates. This means that if you generate an async method, the async method can assert that it got a callback.