Hi, On Thu, Nov 13, 2025 at 4:25 PM Edmond Dantes <[email protected]> wrote:
> 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. > It's 1.6k lines so it might help a little bit > 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. > I don't think you can create PR with the whole project. It's not gonna get reviewed and merged. It might not even open in GH. So you will need to come up with a way how to split to small pieces and I think this is the first self contained bit that should be offered in minimal form. > > ** 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. > > Why do you need reactor for this specific part of proposal? The thing is that there shouldn't be any IO so you reduce scheduler code as well and make it simpler and more reviewable. Kind regards, Jakub
