Hi, On Sun, Nov 16, 2025 at 7:58 AM Edmond Dantes <[email protected]> wrote:
> Hello > > > Maybe that’s inherent to a subject matter that indeed could be the > biggest change to PHP since 7, > > but given RFC voting history, all signs point to a rejection vote. > > I think so too. > > It looks like it but it's hard to say because many people have not had chance to review / comment on this. I think it needs more time and the RFC text needs more work to explain the basic difference. I think it also need to have a good implementation for what is being proposed to have any chance because there are often voters that will vote down just because there is no implementation that can be reviewed. Basically everything that can be addressed should be addressed before the vote so it's just decisions between the actual approach. > > I don’t know how much has been discussed off list and/or how many voters > are involved off list. > > There were almost no discussions apart from the one on INTERNALS. I > mean, there were no discussions that I’m aware of. > > I don’t know what to do about a situation where PHP developers are > surprised to learn that their language has supported transparent > asynchrony as a core paradigm for several years already. > And instead of discussing the important details of the RFC, all the > effort goes into “basic questions” that aren’t worth discussing at > all. > I think this is more that some people clearly prefer coloring and want to point out the potential issues with this approach. This might be quite hard to overcome and depends how many voters have such preference. Personally I agree that coloring would be bad for PHP as I was dealing with "coloring migration" in Python and it wasn't nice. That's why I think it might help to have dedicated section about coloring (more comparison with the current approach) in the RFC. Kind regards, Jakub
