Hello Jakub. > I think it would be good to see the implementation that can cover the > currently proposed API and try to strip it as much as possible so it doesn't > contain much more than that. We saw that PR for the async API was already > quite > big and we didn't really get any agreement there partially also because there > was no user of that and it was not possible to have any tests for it (without > writing them in C). > So what I'm thinking is that if some minimal version that implements just > this (e.g. reactor can be just dummy because there is no io atm. and other > things can be stripped too), then the voters would get better idea what they > are > dealing with and could even try it out.
I understand what you mean. ** Regarding simplifying the code.** Any “simplification” essentially comes down to removing stub files and the C classes that implement the PHP classes. This is a relatively small part of the project. For example, removing Scope from the C code doesn’t make much sense, because it turned out (even unintentionally) to be a very convenient structure for tracking a group of coroutines. In other words, no major changes to the code are expected before the PR review begins. ** Reactor. ** Since the reactor uses libUV and we currently do not plan to provide a pure-C implementation, we agreed to move it into a separate library. ** Testing. ** Some functions that do not involve I/O can be covered by unit tests. This is a small portion of the API. However, covering all the remaining code that performs I/O with unit tests is not practical. We could try to emulate the OS and so on… but I think you understand that the result is not worth the effort. This means we cannot avoid integration tests. P.S. Personally, I would prefer to agree on the PR first and the RFC afterwards. As I mentioned earlier, the code is more important than the RFC, because it defines the real relationships and logic, while the RFC only “describes” them. But we live in a world that follows its own rules. --- Ed
