> > > 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 marco.rog...@gmail.com | https://twitter.com/polotek Life is ten percent what happens to you and ninety percent how you respond to it. - Lou Holtz
