>> 
>> As for the application, reasoning about code that looks like hash-table 
>> lookup but acts very different may not be better than reasoning about code 
>> that looks like spaghetti but acts like you expect.
> 
> The two are not easy to trade off. Spaghetti is the bigger problem, IMHO, 
> since you can make proxies behave well (unlike host objects, e.g. DOM 
> nodelists, which can be implemented with proxies [with a few edge-case 
> extensions] but which act like "live cursors").
> 
> API design taste is still required to avoid making gratuitously magical 
> objects. Promises are a non-magical use-case, IMHO.

This is what is starting to happen in practice.

Node programs work with Streams (objects that emit data). Node defines some 
important core objects (HTTP requests and responses, files, etc) that are all 
Streams.

Libraries define Stream objects that take an input stream and pipe themselves 
to an output stream.

Those objects have a user defined state and other state that gets defined by 
their inputs and outputs.

There are little to no callbacks in the application code, it's all in libraries 
that are handling the state changes.

Example:

http://www.mikealrogers.com/posts/request-20.html

Yes, these are "promisy" objects in that they have different events and state 
changes in the future. They are different from most generic promise proposals 
in that they require initializing state to be setup in one call from the event 
loop (before nextTick() in node.js).

Spagetti code is mostly found in poor programs and contrived examples.

Streams and pipes as flow control, that's how good node programs work. We can't 
move everything to generators because Streams and pipes also have semantics for 
handling back pressure through event propagation. Nor can we take an 
off-the-shelf promise and/or defer that doesn't emit events, for the same 
reason.

None of the proposed alternative IO handlers for node, Harmony proposals, 
fibers, coro, whatever, give us a simpler HTTP proxy than:

http.createServer(function (req, resp) {
  req.pipe(request(req.url)).pipe(resp)
})

This is why i get a little pissed when people who aren't writing node.js 
programs tell me about "spaghetti code".

-Mikeal



_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to