Michael,
As the person empowered to make definitive statements about the
direction of Node, here's the answer:
Wherever it makes sense (for some definition of "sense", of course),
Node's file system api follows the Posix patterns.
Stat, lstat, and fstat all return the same type of object. Of co
>
> files.map(function(file){
> fs.stat(file,function(stats){
> if(stats.isFile()){
> fs.readFile(file, function(err, theFile){
> //dosomething
> })
> }
> })
> })
>
I don't think this example is correct, the variable "file"
in fs.readFile(file, function(err,
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 clo
I'm certainly no expert, but I expect the design choice was made to do it
that way to make the C/C++ asynchronous calls within the node core to be
simpler and easier. At present, to jump back into the callback the C++ side
just needs a single function reference. If a list of arbitrary arguments
are
2012 6:53 AM
To: nodejs@googlegroups.com
Subject: Re: [nodejs] Re: Why no additional parameters in (async.
node.js API) callback functions?
I know how I can do it (at least 3 different very ways came to my mind
immediately), I said so ;-) - that was't my question (or point).
I don't WANT
At least with my .bind() example one could argue that it makes the code
harder to read (yes, I completely agree with you about closure hell; and
they are way less understandable than what I am about to say): it has to do
with expression of intent. To the untrained eye, what is going on here?
fs
I know how I can do it (at least 3 different very ways came to my mind
immediately), I said so ;-) - that was't my question (or point).
I don't WANT to have to write that, if I can help it.
I would except the explanation that since node.js is very low-level
burdening the API functions with an add
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
mill
Sir, you did not understand my question :)
However, I don't see how I could possibly be clearer - which
definitely is MY shortcoming. So sorry.
On Wed, Dec 12, 2012 at 11:59 AM, greelgorke wrote:
> why? its the simpliest and most common way, that's it. passing by custom
> params has to be impl