Stop arguing. Let's have them all. They all have different semantic values that are handy.
Old guys: setTimeout === I don't care when these will happen, just that they will happen eventually, sometime later. I don't care about their order. I also want to keep a reference, in case I want to cancel them. nextTick === I want the stuff I call to run first on the next tick, in the order I called them. I'm never gonna need to cancel these. New guys: setImmediate === Similar to nextTick but with a reference, so I may cancel it during this tick, or within an afterTick/nextTick call. afterTick === Before jumping to the next tick, and after this tick has ran to completion, run these in order. In perspective: tick...nextTick stuff...setImmediate stuff...everything else I don't care about their order, setTimeouts, events etc...afterTick stuff...tick..... --stagas 2012/5/31 Jorge <jo...@jorgechamorro.com>: > If there are bugs in node's internal libraries/code due to nextTick()'s > current behaviour, they can simply rewrite nextTick() as they please into a > *new* method with a *different* name such as e.g. thisTick, and do an > s/nextTick/thisTick/g onto node's source code and that's it. > > But there's no need to touch (such an essential piece of) node's public API > (and fuck all its users and their programs) to fix node's internal bugs. > -- > Jorge. > > On May 31, 2012, at 10:50 AM, James Howe wrote: > >> The git issue now has good examples of why something higher-priority and >> something lower-priority than the current nextTick compromise are desired. >> As long as not just the higher-priority one is provided, I'll be happy. >> >> On Wednesday, 30 May 2012 15:33:20 UTC+1, Tim Caswell wrote: >> >> >> On Wed, May 30, 2012 at 4:12 AM, James Howe <ja...@howeswho.co.uk> wrote: >> Sorry if I'm being obtuse, but why do you need a special API for >> Do-Work-After-Run-To-Completion? Can that not be achieved just with normal >> program flow-control (i.e. do the work, do the thing after the work, return)? >> >> No. It's impossible to do anything after returning using normal >> control-flow. A perfect example is a function that returns an event >> emitter. The code that attaches event listeners to the emitter *can't* >> attach listeners till you return the emitter. But there are times that you >> want to emit events as soon as possible. nextTick tells node to call your >> function after your caller returns and the whole stack unwinds. >> >> >> Further to my assumptions (and experience) about what nextTick does, it >> seemed obvious to me that you need to set the handlers before you returned >> from the stack to avoid missing data events. Setting them before returning >> doesn't cause any problems, as those events can't be processed until you've >> returned anyway. >> >> And to Mikeal, I have quite sizeable projects that would go wrong if >> nextTick semantics are changed (and we don't find some way to fix them) but >> haven't posted examples because they are a) sizeable, b) closed-source and >> c) I don't have time. >> >> Are you cases where you depend on the current implementation of nextTick >> easy to work around? I know I have tons of code that depends on the current >> behavior, but in every case I could modify my code to not depend on the >> behavior. >> >> Everyone, please read the thread in the gist that Isaac posted. There are >> several proposed new APIs that make it possible to do low-priority work that >> doesn't starve/block the event loop. >> >> >> Regards >> >> >> On Wednesday, 30 May 2012 04:21:58 UTC+1, CrabDude wrote: >> There seem to be 2 considerations: >> >> 1. Adding sameTick() functionality to node. >> 2. Whether nextTick() should house that behavior, or another API / name. >> >> FWIW, I always misunderstood process.nextTick() to occur, as the name >> implies, at the beginning of the next tick. In other words, the name implied >> to me that it would yield to any queued timer / IO events, and then execute >> at the beginning of the next event loop. In fact, b/c of this >> misunderstanding, I found nextTick() and setImmediate() to be eventually >> redundant. >> >> I feel fairly confident in saying that it would be easier for core to >> implement the desired behavior under a different name (sameTick(), etc...) >> and replace all calls to nextTick() with sameTick(), thisTick(), etc..., >> than to change the misperceptions others may have regarding what the >> function name implies, that it in fact actually does not execute until the >> _next_ tick. Changing the behavior of nextTick to something that conflicts >> with its name, would seem to inevitably cause misunderstandings. Core >> obviously (from this thread) though has a different perception of the >> purpose of nextTick, since it seems it has a very specific purpose for which >> it was created and is used. Ironically, those most familiar with its >> *intended purpose* are also those that are most aware that its >> implementation is not always consistent with that purpose. >> >> Is there any reasoning core has regarding why replacing all nextTick() calls >> with thisTick() would be problematic? It is after all new functionality, and >> once again the name nextTick() seems inconsistent with its proposed new >> implementation. >> >> Wouldn't nextTick inevitably be deprecated / replaced by setImmediate >> anyways? It's too bad too, nexTick() is a great name, much nicer than >> "sameTick," "thisTick," etc... >> >> Cheers, >> Adam Crabtree >> >> On Tue, May 29, 2012 at 4:28 PM, Marco Rogers wrote: >> >> The problem with this characterization of the API's history is that it's >> actually not distinguishable from setTimeout(fn, 0) except in >> implementation. As described, they are for quite literally the same thing >> although one of them is a little better at it because of an implementation >> detail. If this characterization is true (i don't believe it is) then we >> should re-purpose or remove nextTick() and improve the performance of >> setTimeout(fn,0). I'm not suggesting that is what we do, but it's the >> logical conclusion to this characterization. >> >> >> This characterization comes from people's real impressions of nextTick. If >> you want to change that impression, you have some work to do. >>> >>> As for whether it's valid to use nextTick or setTimeout or whatever to >>> break up computation, that's not your call. >> >> Are you saying that core can't state the intention of an API? That's insane. >> >> Core is free to change the implementation details and semantics of an API at >> any time, and has on many occasions. This is always done with the intention >> of making it *better*. In order to characterize what is "better" the API >> must have a purpose and that has always been dictated by core (Ryan and then >> Isaac). >> >> As for the purpose of nextTick, I did agree on what the intended purpose >> was. And yes you can change whatever you want. You guys are in charge. And >> we're free to tell you it was a bad idea. You're free to get mad about that. >> And we're free to tell you you're being kind of bratty about it. Everybody's >> free! The only problem here is that you think you're allowed to think you're >> right more than we're allowed to think you're wrong. Strange isn't it? >> >> Let me be clear. I think the problem with missing data events should be >> fixed. But we should evaluate the solutions to make sure they aren't going >> to cause follow on problems that will haunt us. That's what I'm doing here. >> If you don't agree about follow on problems, say that. If you don't want to >> discuss potential follow on problems, say that. If you want to be upset that >> not everybody who uses node has the exact same view of it's affordances as >> you do... well I don't know how to help you with that. >> >> Instead, we got a lot of comments about names and about theoretical breakage >> in code without anyone noting running code that actually breaks or is even >> valid. And now we're being taken down the rabbit hole of "I can't use this >> for something it wasn't designed for". >> >> >> So since a hand full of people who saw this message and decided to respond >> don't have concrete use cases in hand ready to go, you can dismiss all >> concerns? That's crap. We *should* find some use cases, but that doesn't >> mean the discussion here isn't useful or that we can't reason about what >> might happen. Reasoning about semantics is how programming works. Or at >> least that's usually how I do it. >> >> The way in which people are providing feedback to this proposed changed is >> unproductive because they do not recognize the reality of the current >> semantics. >> 1) that we cannot remove nextTick() and it is heavily relied on. >> 2) that much of the code that *currently* relies on nextTick() breaks under >> heavy load because of the current implementation. >> >> All of this feedback is "me too". It's statements of opinion without >> reference the problem that must be solved. >> >> There's some truth to this. As I said, the problem to be solved is >> important. But pretending it's the only thing that's important and that >> there isn't potential to cause other problems is ludicrous. Also ludicrous >> is bullying and yelling at people who came here to discuss things with you >> in good faith precisely because we care deeply about node and the direction >> it goes in. Try to get some perspective here man. Also try meditation. >> >> >> The intention of feedback should be to change the minds of those that >> proposed the change, not to prove that your'e right under your terms. >> >> I don't think that's what anyone here has done. I even started out by saying >> I may need to be educated about this. But I also think you and other core >> guys are sometimes obtuse and dismissive about how non-core people actually >> build their mental model about node execution and how that affects the >> solutions they come up with. I'm not giving you *my* terms. I'm giving you >> the terms I've gotten from talking to a lot of people who are not node >> experts. And as much as node benefits from not having the baggage of >> traditional notions of i/o, it does have the baggage of people's long >> experience with javascript execution. You can ignore that useful data at >> your peril. >> >> :Marco >> >> -- >> Marco Rogers >> >> Life is ten percent what happens to you and ninety percent how you respond >> to it. >> - Lou Holtz >> >> >> >> -- >> Better a little with righteousness >> than much gain with injustice. >> Proverbs 16:8 >> >> On Wednesday, 30 May 2012 04:21:58 UTC+1, CrabDude wrote: >> There seem to be 2 considerations: >> >> 1. Adding sameTick() functionality to node. >> 2. Whether nextTick() should house that behavior, or another API / name. >> >> FWIW, I always misunderstood process.nextTick() to occur, as the name >> implies, at the beginning of the next tick. In other words, the name implied >> to me that it would yield to any queued timer / IO events, and then execute >> at the beginning of the next event loop. In fact, b/c of this >> misunderstanding, I found nextTick() and setImmediate() to be eventually >> redundant. >> >> I feel fairly confident in saying that it would be easier for core to >> implement the desired behavior under a different name (sameTick(), etc...) >> and replace all calls to nextTick() with sameTick(), thisTick(), etc..., >> than to change the misperceptions others may have regarding what the >> function name implies, that it in fact actually does not execute until the >> _next_ tick. Changing the behavior of nextTick to something that conflicts >> with its name, would seem to inevitably cause misunderstandings. Core >> obviously (from this thread) though has a different perception of the >> purpose of nextTick, since it seems it has a very specific purpose for which >> it was created and is used. Ironically, those most familiar with its >> *intended purpose* are also those that are most aware that its >> implementation is not always consistent with that purpose. >> >> Is there any reasoning core has regarding why replacing all nextTick() calls >> with thisTick() would be problematic? It is after all new functionality, and >> once again the name nextTick() seems inconsistent with its proposed new >> implementation. >> >> Wouldn't nextTick inevitably be deprecated / replaced by setImmediate >> anyways? It's too bad too, nexTick() is a great name, much nicer than >> "sameTick," "thisTick," etc... >> >> Cheers, >> Adam Crabtree >> >> On Tue, May 29, 2012 at 4:28 PM, Marco Rogers wrote: >> >> The problem with this characterization of the API's history is that it's >> actually not distinguishable from setTimeout(fn, 0) except in >> implementation. As described, they are for quite literally the same thing >> although one of them is a little better at it because of an implementation >> detail. If this characterization is true (i don't believe it is) then we >> should re-purpose or remove nextTick() and improve the performance of >> setTimeout(fn,0). I'm not suggesting that is what we do, but it's the >> logical conclusion to this characterization. >> >> >> This characterization comes from people's real impressions of nextTick. If >> you want to change that impression, you have some work to do. >>> >>> As for whether it's valid to use nextTick or setTimeout or whatever to >>> break up computation, that's not your call. >> >> Are you saying that core can't state the intention of an API? That's insane. >> >> Core is free to change the implementation details and semantics of an API at >> any time, and has on many occasions. This is always done with the intention >> of making it *better*. In order to characterize what is "better" the API >> must have a purpose and that has always been dictated by core (Ryan and then >> Isaac). >> >> As for the purpose of nextTick, I did agree on what the intended purpose >> was. And yes you can change whatever you want. You guys are in charge. And >> we're free to tell you it was a bad idea. You're free to get mad about that. >> And we're free to tell you you're being kind of bratty about it. Everybody's >> free! The only problem here is that you think you're allowed to think you're >> right more than we're allowed to think you're wrong. Strange isn't it? >> >> Let me be clear. I think the problem with missing data events should be >> fixed. But we should evaluate the solutions to make sure they aren't going >> to cause follow on problems that will haunt us. That's what I'm doing here. >> If you don't agree about follow on problems, say that. If you don't want to >> discuss potential follow on problems, say that. If you want to be upset that >> not everybody who uses node has the exact same view of it's affordances as >> you do... well I don't know how to help you with that. >> >> Instead, we got a lot of comments about names and about theoretical breakage >> in code without anyone noting running code that actually breaks or is even >> valid. And now we're being taken down the rabbit hole of "I can't use this >> for something it wasn't designed for". >> >> >> So since a hand full of people who saw this message and decided to respond >> don't have concrete use cases in hand ready to go, you can dismiss all >> concerns? That's crap. We *should* find some use cases, but that doesn't >> mean the discussion here isn't useful or that we can't reason about what >> might happen. Reasoning about semantics is how programming works. Or at >> least that's usually how I do it. >> >> The way in which people are providing feedback to this proposed changed is >> unproductive because they do not recognize the reality of the current >> semantics. >> 1) that we cannot remove nextTick() and it is heavily relied on. >> 2) that much of the code that *currently* relies on nextTick() breaks under >> heavy load because of the current implementation. >> >> All of this feedback is "me too". It's statements of opinion without >> reference the problem that must be solved. >> >> There's some truth to this. As I said, the problem to be solved is >> important. But pretending it's the only thing that's important and that >> there isn't potential to cause other problems is ludicrous. Also ludicrous >> is bullying and yelling at people who came here to discuss things with you >> in good faith precisely because we care deeply about node and the direction >> it goes in. Try to get some perspective here man. Also try meditation. >> >> >> The intention of feedback should be to change the minds of those that >> proposed the change, not to prove that your'e right under your terms. >> >> I don't think that's what anyone here has done. I even started out by saying >> I may need to be educated about this. But I also think you and other core >> guys are sometimes obtuse and dismissive about how non-core people actually >> build their mental model about node execution and how that affects the >> solutions they come up with. I'm not giving you *my* terms. I'm giving you >> the terms I've gotten from talking to a lot of people who are not node >> experts. And as much as node benefits from not having the baggage of >> traditional notions of i/o, it does have the baggage of people's long >> experience with javascript execution. You can ignore that useful data at >> your peril. >> >> :Marco >> >> -- >> Marco Rogers >> >> Life is ten percent what happens to you and ninety percent how you respond >> to it. >> - Lou Holtz >> >> >> >> -- >> Better a little with righteousness >> than much gain with injustice. >> Proverbs 16:8 >> >> On Wednesday, 30 May 2012 04:21:58 UTC+1, CrabDude wrote: >> There seem to be 2 considerations: >> >> 1. Adding sameTick() functionality to node. >> 2. Whether nextTick() should house that behavior, or another API / name. >> >> FWIW, I always misunderstood process.nextTick() to occur, as the name >> implies, at the beginning of the next tick. In other words, the name implied >> to me that it would yield to any queued timer / IO events, and then execute >> at the beginning of the next event loop. In fact, b/c of this >> misunderstanding, I found nextTick() and setImmediate() to be eventually >> redundant. >> >> I feel fairly confident in saying that it would be easier for core to >> implement the desired behavior under a different name (sameTick(), etc...) >> and replace all calls to nextTick() with sameTick(), thisTick(), etc..., >> than to change the misperceptions others may have regarding what the >> function name implies, that it in fact actually does not execute until the >> _next_ tick. Changing the behavior of nextTick to something that conflicts >> with its name, would seem to inevitably cause misunderstandings. Core >> obviously (from this thread) though has a different perception of the >> purpose of nextTick, since it seems it has a very specific purpose for which >> it was created and is used. Ironically, those most familiar with its >> *intended purpose* are also those that are most aware that its >> implementation is not always consistent with that purpose. >> >> Is there any reasoning core has regarding why replacing all nextTick() calls >> with thisTick() would be problematic? It is after all new functionality, and >> once again the name nextTick() seems inconsistent with its proposed new >> implementation. >> >> Wouldn't nextTick inevitably be deprecated / replaced by setImmediate >> anyways? It's too bad too, nexTick() is a great name, much nicer than >> "sameTick," "thisTick," etc... >> >> Cheers, >> Adam Crabtree >> >> On Tue, May 29, 2012 at 4:28 PM, Marco Rogers wrote: >> >> The problem with this characterization of the API's history is that it's >> actually not distinguishable from setTimeout(fn, 0) except in >> implementation. As described, they are for quite literally the same thing >> although one of them is a little better at it because of an implementation >> detail. If this characterization is true (i don't believe it is) then we >> should re-purpose or remove nextTick() and improve the performance of >> setTimeout(fn,0). I'm not suggesting that is what we do, but it's the >> logical conclusion to this characterization. >> >> >> This characterization comes from people's real impressions of nextTick. If >> you want to change that impression, you have some work to do. >>> >>> As for whether it's valid to use nextTick or setTimeout or whatever to >>> break up computation, that's not your call. >> >> Are you saying that core can't state the intention of an API? That's insane. >> >> Core is free to change the implementation details and semantics of an API at >> any time, and has on many occasions. This is always done with the intention >> of making it *better*. In order to characterize what is "better" the API >> must have a purpose and that has always been dictated by core (Ryan and then >> Isaac). >> >> As for the purpose of nextTick, I did agree on what the intended purpose >> was. And yes you can change whatever you want. You guys are in charge. And >> we're free to tell you it was a bad idea. You're free to get mad about that. >> And we're free to tell you you're being kind of bratty about it. Everybody's >> free! The only problem here is that you think you're allowed to think you're >> right more than we're allowed to think you're wrong. Strange isn't it? >> >> Let me be clear. I think the problem with missing data events should be >> fixed. But we should evaluate the solutions to make sure they aren't going >> to cause follow on problems that will haunt us. That's what I'm doing here. >> If you don't agree about follow on problems, say that. If you don't want to >> discuss potential follow on problems, say that. If you want to be upset that >> not everybody who uses node has the exact same view of it's affordances as >> you do... well I don't know how to help you with that. >> >> Instead, we got a lot of comments about names and about theoretical breakage >> in code without anyone noting running code that actually breaks or is even >> valid. And now we're being taken down the rabbit hole of "I can't use this >> for something it wasn't designed for". >> >> >> So since a hand full of people who saw this message and decided to respond >> don't have concrete use cases in hand ready to go, you can dismiss all >> concerns? That's crap. We *should* find some use cases, but that doesn't >> mean the discussion here isn't useful or that we can't reason about what >> might happen. Reasoning about semantics is how programming works. Or at >> least that's usually how I do it. >> >> The way in which people are providing feedback to this proposed changed is >> unproductive because they do not recognize the reality of the current >> semantics. >> 1) that we cannot remove nextTick() and it is heavily relied on. >> 2) that much of the code that *currently* relies on nextTick() breaks under >> heavy load because of the current implementation. >> >> All of this feedback is "me too". It's statements of opinion without >> reference the problem that must be solved. >> >> There's some truth to this. As I said, the problem to be solved is >> important. But pretending it's the only thing that's important and that >> there isn't potential to cause other problems is ludicrous. Also ludicrous >> is bullying and yelling at people who came here to discuss things with you >> in good faith precisely because we care deeply about node and the direction >> it goes in. Try to get some perspective here man. Also try meditation. >> >> >> The intention of feedback should be to change the minds of those that >> proposed the change, not to prove that your'e right under your terms. >> >> I don't think that's what anyone here has done. I even started out by saying >> I may need to be educated about this. But I also think you and other core >> guys are sometimes obtuse and dismissive about how non-core people actually >> build their mental model about node execution and how that affects the >> solutions they come up with. I'm not giving you *my* terms. I'm giving you >> the terms I've gotten from talking to a lot of people who are not node >> experts. And as much as node benefits from not having the baggage of >> traditional notions of i/o, it does have the baggage of people's long >> experience with javascript execution. You can ignore that useful data at >> your peril. >> >> :Marco >> >> -- >> Marco Rogers >> >> Life is ten percent what happens to you and ninety percent how you respond >> to it. >> - Lou Holtz >> >> >> >> -- >> Better a little with righteousness >> than much gain with injustice. >> Proverbs 16:8 >> >
