> To provide an explicit example for this, code that fits this pattern is going > to be problematic
Why is this considered a problem if this behavior is part of the language’s contract? Exactly the same way as in Go for example, this is also part of the contract between the language and the programmer. > $this->data can be changed out from under writeData(), which leads to > unexpected behavior. So the developer must intentionally create two different coroutines. Intentionally pass them the same object. Intentionally write this code. And the behavior is called “unexpected”? :) > that it is working "exactly the same" with coroutines by ignoring that it is > now wrong I understand that a word written by one person can be interpreted however another person feels like. Language is not a reliable carrier of information, so people must take context into account to extract useful information with minimal distortion. The changes described in the RFC refer to the algorithm for handling I/O functions in blocking mode. And of course these words assume that we haven’t lost our minds and understand that you cannot write completely different message sequences to the same socket at the same time. In practice, changes are of course sometimes necessary, but throughout my entire experience working with coroutines, I should note that I have never once run into the example you mentioned. Even when adapting older projects. And do you know why? Because the first thing we refactored in the old code was the places with shared variables. > There is no way in general for code written without coroutines or async > suspensions in mind to work correctly if it can be suspended. Agreed. A developer must understand that potentially any function can interrupt execution. This is a consequence of transparent asynchrony. It is both its strength and its weakness. I will repeat it again: not some specific function, but almost ANY function. Because under transparent asynchrony you can use suspend() inside any function. This does not negate the fact that documentation should list all functions that switch context, but a certain coding style encourages this way of thinking. Modern programming languages strive for clarity and cleanliness. In other words, colored functions provide code clarity and prevent errors caused by misunderstanding what a function does. Critics of colored functions criticize them precisely for what is actually their strength, not their weakness. Color is an advantage. But in PHP, colored functions are inconvenient. Overloading I/O functions does not lead to serious errors that make developers suffer; on the contrary, it saves time and gives the language more flexibility. I can explain why. The amount of code that works with sockets in PHP is generally several times smaller than the code that works with databases. In other words, the modules where such errors could occur are simply not that many. They do exist. library clients... but compared to all other code, there are far fewer of them. And as it turns out, refactoring them for coroutines requires very few changes. Especially if the code was already well-written with best practices in mind, then it will most likely work excellently with coroutines with minimal adjustments. How did we refactor old code for coroutines? 1. We took the modules that had global state. There were not many of them. 2. We used a Context, which is essential, and moved the global state into the context. I don’t remember exactly how many thousands of lines of code there were, but definitely more than 20,000. But why anyone would intentionally pass the same object to different coroutines and then complain that the code broke. I have no idea who would need that. :) A developer should strive to minimize asynchronous code in a project. The less of it there is, the better. Asynchronous code is evil. An anti-pattern. A high-complexity zone. But if a developer chooses to use asynchronous code, they shouldn’t act like they’re three years old and seeing a computer for the first time. Definitely not. This technology requires steady, capable hands :) Best Regards, Ed.
