Right, I get that.
On Sep 1, 2013, at 8:59 AM, dhruvbird dhruvb...@gmail.com wrote:
@Bryan: Be careful when using the EventEmitter like pattern because:
var e = new ObjectDerivingFromEventEmitter()
e.makeRequest(request_parameters);
e.on('error', function() { });
Now, if makeRequest()
On Thu, Aug 29, 2013 at 3:16 AM, Isaac Schlueter i...@izs.me wrote:
http://blog.izs.me/post/59142742143/designing-apis-for-asynchrony
Nice article, although I think the whole first section is out of
place. You spend a whole page on explaining why your choice of
abstraction doesn't matter. And
On Fri, Aug 30, 2013 at 5:24 AM, Juraj Kirchheim back2...@gmail.com wrote:
On Thu, Aug 29, 2013 at 3:16 AM, Isaac Schlueter i...@izs.me wrote:
http://blog.izs.me/post/59142742143/designing-apis-for-asynchrony
Nice article, although I think the whole first section is out of
place. You spend
Calm your tone. It's not a lie. It's just something that you seem not
to understand.
If you actually care for an explanation, I will be glad to give you one.
But if you're just into screaming lie at things that you cannot
grasp, then I will spare both of us a further waste of time.
--
--
Job
On Fri, Aug 30, 2013 at 8:30 AM, Juraj Kirchheim back2...@gmail.com wrote:
Calm your tone. It's not a lie. It's just something that you seem not
to understand.
If you actually care for an explanation, I will be glad to give you one.
But if you're just into screaming lie at things that you
Many years ago I used to write functions that *almost* always returned
promises, except when they didn't. And I thought it was great, and
efficient. I just needed to lift the values of a *possible promises* into
an actual promises using something like Q.when. This works wonderfully,
until you hit
On Fri, Aug 30, 2013 at 9:08 AM, Dean Landolt d...@deanlandolt.com wrote:
Which means you have to wrap pretty much any zalgo-promise, or use some
goofy apply mechanism. Assuming you meticulously add all this boilerplate
then yes, at this point Juraj is right. It solves the problem (with a
You say this sounds like the opposite of promises solving a problem,
which I assume would mean promises creating a problem? This obviously
conflicts with the abstraction not mattering part. Everything I said was
to reinforce the point that the abstraction doesn't matter and demonstrate
how zalgo's
On Aug 29, 2013, at 7:09 PM, Isaac Schlueter i...@izs.me wrote:
On Thu, Aug 29, 2013 at 11:19 AM, Bryan Donovan brdono...@gmail.com wrote:
Thanks, I just wanted to make sure my understanding was correct in that
there really is no problem with the specific case I presented.
That
On Fri, Aug 30, 2013 at 10:15 AM, Dean Landolt d...@deanlandolt.com wrote:
You say this sounds like the opposite of promises solving a problem,
which I assume would mean promises creating a problem?
No, they're certainly not creating a problem. It's just that the asynchrony
inconsistency
Yeah, I really dislike this pattern. It's confusing at best. I never
understood the reason for designing an API this way. I suspect it has
something to do with emitting events, like in the http module.
On Aug 30, 2013, at 9:48 AM, Paul pseld...@gmail.com wrote:
That means never doing
Same with us. 2 years, no problems even though Zalgo is released all over
the place with error checking code.
I think we get avoid any problems by just assuming that any callbacks could
be called synchronously.
That means never doing something that seems dirty like this:
var thing =
You've actually highlighted the problem in your response. The part where
you essentially say you're doing it wrong. The whole point of forced
asynchrony is that it makes it impossible for the user to do it wrong. Yes,
if we write the code in the order we want, and we always generate the
promise
I believe that labeling a statement you disagree with a flat out lie
is a pointlessly harsh response. But arguably calling that screaming
is just as inadequate. I apologize ;)
Now to the point. If you're facing this problem using promises, I
would argue that you're using promises the wrong way -
Just want to clarify something. process.nextTick has practically zero cost,
even at the micro level. You'll only see the overhead if you're calling it 100k
times/sec. Even then it's in the milliseconds. I've been doing optimizations
and performance analysis on this for months. Trust me that
Thanks for the post, Isaac. Very helpful.
I totally understand the logic of being consistent -- I'm known to be ruthless
about consistency at work. I'm changing my public node.js libraries to use
nextTick() instead of calling back immediately.
However, I'm still unsure of when someone would
On Thu, Aug 29, 2013 at 12:51 PM, Bryan Donovan brdono...@gmail.com wrote:
However, I'm still unsure of when someone would ever care if I called back
immediately in my examples, where I'm just checking for the correct args.
Oleg's generic example seemed pretty clear to me:
That's not the same situation though. What bad can happen in my most recent
example?
On Aug 29, 2013, at 9:57 AM, Scott González scott.gonza...@gmail.com wrote:
On Thu, Aug 29, 2013 at 12:51 PM, Bryan Donovan brdono...@gmail.com wrote:
However, I'm still unsure of when someone would ever
Yes, it's possible to construct specific situations that don't have
problems. Nobody is denying that. But it's irrelevant if it's also possible
to construct situations that do have problems.
On Thu, Aug 29, 2013 at 1:50 PM, Bryan Donovan brdono...@gmail.com wrote:
That's not the same situation
Thanks, I just wanted to make sure my understanding was correct in that there
really is no problem with the specific case I presented.
On Aug 29, 2013, at 11:16 AM, Scott González scott.gonza...@gmail.com wrote:
Yes, it's possible to construct specific situations that don't have problems.
But it's irrelevant if it's also possible to construct situations that
do have problems.
That is illogical. Code that is bulletproof is always OK. You are
confusing philosophy with practice.
On Thu, Aug 29, 2013 at 11:19 AM, Bryan Donovan brdono...@gmail.com wrote:
Thanks, I just wanted
But if you are talking about providing a library to others then that is not
bulletproof. I was only thinking of my own code, which uses mixed sync and
async all the time.
On Thu, Aug 29, 2013 at 12:51 PM, Mark Hahn m...@reevuit.com wrote:
But it's irrelevant if it's also possible to
On Thu, Aug 29, 2013 at 9:51 AM, Bryan Donovan brdono...@gmail.com wrote:
I totally understand the logic of being consistent
You say this. And yet, you release Zalgo right away in your example!
Never ever do this!
However, I'm still unsure of when someone would ever care if I called back
On Thu, Aug 29, 2013 at 11:19 AM, Bryan Donovan brdono...@gmail.com wrote:
Thanks, I just wanted to make sure my understanding was correct in that
there really is no problem with the specific case I presented.
That understanding is incorrect.
The exact problem being described in Havoc's post
The bottom line is *APIs should be consistent in behavior*.
On Fri, Aug 30, 2013 at 7:39 AM, Isaac Schlueter i...@izs.me wrote:
On Thu, Aug 29, 2013 at 11:19 AM, Bryan Donovan brdono...@gmail.com
wrote:
Thanks, I just wanted to make sure my understanding was correct in that
there really
Bryan,
I wrote this for you.
http://blog.izs.me/post/59142742143/designing-apis-for-asynchrony
On Fri, Aug 23, 2013 at 10:58 AM, Scott González
scott.gonza...@gmail.com wrote:
On Fri, Aug 23, 2013 at 1:46 PM, Chaoran Yang chaoran.y...@gmail.com
wrote:
I have never seen such cases ... and
This all are good arguments, in the theory ... in praxis, I think:
1. Most developers do not assume async/sync mixed styles today ...
2. That kind of performance overhead matters in some rare cases, I think ...
normally you don't care about 10-15ms ... If the overhead is much higher its
about
On Friday, August 23, 2013 10:21:37 AM UTC-5, Oleg Slobodskoi wrote:
This all are good arguments, in the theory ... in praxis, I think:
1. Most developers do not assume async/sync mixed styles today ...
In practice, coding standard should not be lower because of programmer
laziness,
On Friday, August 23, 2013 10:21:37 AM UTC-5, Oleg Slobodskoi wrote:
This all are good arguments, in the theory ... in praxis, I think:
1. Most developers do not assume async/sync mixed styles today ...
In practice, coding standard should not be lower because of programmer
laziness,
This is certainly only way I've ever programmed in node.js. I really don't like
APIs like this:
var client = connect(function() {
client.do_something(function() {
//..
});
});
… they're just weird. This makes a lot more sense to me:
Depends on how much pain it causes ... If official nodejs doc warns people
then its probably fine ...
I just found out official nodejs doc has that in there, which is a very bad
idea I think.
I have never seen such cases ... and can't imagine them ... but potentially
yes ...
The
On Fri, Aug 23, 2013 at 1:46 PM, Chaoran Yang chaoran.y...@gmail.comwrote:
I have never seen such cases ... and can't imagine them ... but
potentially yes ...
The cursor.nextObject() of
node-mongodb-nativehttps://github.com/mongodb/node-mongodb-native/blob/master/lib/mongodb/cursor.js#L678
Here is another real world example:
var todo = 0;
function done() {
todo--;
if (!todo) callback();
}
todo++;
// If a calls back synchronously, todo amount will never be 2, so done
will call back directly after a calls back.
a(done);
if (soemthing) {
todo++;
b(done);
}
The potential issue is if the person consuming your API expects the
callback to always be async:
// kick off the async process as early as possible
doAsync( cb );
// do some slightly high cost prep work before the callback is invoked
prepareStateForCallbackWhileWaiting();
Doing the prep work
On 20 August 2013 at 1:47:45 PM, Bryan Donovan (brdono...@gmail.com) wrote:
I have been writing node.js client code for a couple of years now, and have
authored a couple open source libraries, but somehow I missed the memo telling
me that I'm supposed to wrap 'synchrounous' callbacks in
I have been writing node.js client code for a couple of years now, and have
authored a couple open source libraries, but somehow I missed the memo
telling me that I'm supposed to wrap 'synchrounous' callbacks in
process.nextTick(). I kind-of understand why that is a best-practice, but
what I
Thanks Scott.
That's basically what I had gathered from googling around. It seems to me like
it's not necessary to wrap in nextTick for most cases then.
On Aug 20, 2013, at 10:58 AM, Scott González scott.gonza...@gmail.com wrote:
The potential issue is if the person consuming your API
37 matches
Mail list logo
