i meant not pure functionAL style, but pure
functions: http://en.wikipedia.org/wiki/Pure_function
the state of the art at the moment is to use closures, which often are not
pure functions. they close over some values from the parent scope, that is
not under control of the closure itself. the closure scope acts as implicit
parameter or state (or dependency) to that closure. that is the case where
you need nesting closures.
Function#bind is one way to replace the need for closing over the parent
context and reduce the nesting to the depth of 1 (without control
structures). same would happen if the parameters would be carried over via
the async-func itself. both methods make the implicit parameters from
closure-scope explicit. the libs may add additional parameter, which may be
a hash or an array, which should be carried other to the callback.
but, all 3 ways will not really reduce callback spaghetti, in some cases
the bind- and the param-carry-overapproach will even reduce readability,
when the parts of an algorithm are separated into code, that calles the
async function, and the closure, and the closure is defined somewhere apart
from the caller, asume the onStat definition in a separate file (for
reuse). you still have to chain the calls in some way.
i think it's the matter of being used to. the nested callbacks seem to me
sometimes to be just an async-replacement for heavy nested loop/condition
statements:
for(file in files){
if(fs.stat(file).isFile()){
theFile = fs.readFile(file)
if( theFile){
//doSomething
}
}
}
vs.
files.map(function(file){
fs.stat(file,function(stats){
if(stats.isFile()){
fs.readFile(file, function(err, theFile){
//dosomething
})
}
})
})
so nesting the callbacks may be even helpfull, because they present the
asyncronous algorithm in the same way as synchronous code would do. but of
cause you could use aync lib to line up them more, but thats an other story.
Am Mittwoch, 12. Dezember 2012 12:21:58 UTC+1 schrieb Michael Hasenstein:
>
> CORRECTION, I take my last statement back, you DID add to the
> conversation and I am a bad reader.
>
> I had already considered the performance issue of having the API
> functions not just call the callback, but also having to handle
> OPTIONAL additional parameters, which in node.js might happen some
> millions of times per second.
>
> A definitive statement in that direction is what I'm actually looking
> for, if THAT was indeed the reason. I dislike nesting my functions,
> even though pure functional style would go A LOT deeper (with the
> nesting) :)
>
>
>
>
> On Wed, Dec 12, 2012 at 12:16 PM, Ruben Tan <sog...@gmail.com<javascript:>>
> wrote:
> > I think you meant "closure". clojure is a language running on JVM.
> >
> > On Wednesday, December 12, 2012 6:59:56 PM UTC+8, greelgorke wrote:
> >>
> >> why? its the simpliest and most common way, that's it. passing by
> custom
> >> params has to be implemented in the async function itself, there is no
> >> native support in js nor node for this. and since use of clojures is
> very
> >> common in js world, mostly noone cares about it. but yes it may help to
> >> un-clutter the callbacks a bit and helpt to build pure functions with
> >> explicit parameters. but i doubt that it would be a performance
> improvement,
> >> because v8 optimized clojurescope-access very well, see here
> >> http://jsperf.com/bind-vs-clojure/2
>
--
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
