>
> I was looking at streamlinejs's wrappers [8], which seemed potentially
> helpful, but streamlinejs is kind of weird.
>
tests: if (asyncCond(_)) { foo.asyncCall(_).bar(); }
loops: while (asyncCond(_)) { foo.asyncCall(_).bar(); }
exceptions: try { foo.asyncCall(_).bar(); } catch (ex) { handleAsync(_,
ex); }
invariants: try { foo.breakMe(_).bar(); } finally { restoreMe(_); }
stream read: var data = st.read(_, len);
stream write: st.write(_, data);
To me, this is the closest you can get to classical JavaScript and basic
Unix I/O: a language with keywords to do the control flow, and simple
read/write/close calls to deal with streams (no risk of losing data, no
need to deal with low level flow control issues).
Of course this is not really fancy: for/while/try/catch/... are boring
language constructs that have been around for ages; read/write/close APIs
are kinda boring too. No glitter here :-(. Streamline.js sends you back to
old (but proven) programming patterns.
But it it is not C anymore, it is JS (not exactly though but as close as
possible to it). And it is not synchronous Unix calls anymore, it is 100%
async node.js callback based calls. And there is even a bit of room for
some fun: futures.
Streamline.js is not about exploring new territories. It is primarily about
bringing you back into territories that you already know: familiar language
keywords and familiar Unix-like APIs.
You can call it "weird". I think that "nostalgic" would be more
appropriate.
Of course, I only represent a very small (but vocal) minority. But I think
that there is a fundamental issue behind this: is async so fundamentally
disruptive that it requires us to completely rethink all our designs? Or is
it only disruptive because we like to explore new territories and we thus
reject old patterns a priori? I find blending the old and the new worlds
much more effective and interesting than trying to re-invent everything.
Going back to the OP's question: why do you have to deal with this problem
in the first place? Because you are using a new design that exposes a new
style of API which does not try to hide flow control but instead forces you
to deal with it everywhere you deal with streams (except when all you need
to do is piping). Maybe there will be an API twist that will provide an
elegant solution to this problem with the new APIs (but I have not seen it
yet and it might turn out to be not so simple). But if you accept to go
back into the old world, the problem is simply gone because flow control is
hidden under a slightly higher level API (read/write) which does not expose
data events (and guarantees that they won't get lost). And believe me, it
just works!
Bruno
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
