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