> > I had a quick look to that PoC and it's basically just a quick wrapper > that depends on GLOB_ALTDIRFUNC. Unfortunately that's a non standard > extension that might be missing on some platform (e.g. alpine won't > probably work because from a quick look the musl libc doesn't seeem to > implement it - https://git.musl-libc.org/cgit/musl/tree/include/glob.h ). > The code obviously needs more work and we will need bunch of tests for > this. Well obviously it's just a PoC but what I want to say is that > implementation is really main thing here and should also help to provide > more details in RFC. For example it's not currently clear that you would > change underlaying glob implementation on some platforms - quite important > thing to mention though. To be honest if there is a good implementation, I > think it's quite unlikely that the RFC will fail. >
Hi Jakub. Indeed, it looks like Alpine users would not benefit from this. I made notes of this in the RFC, thank you. I understand you would have wanted to see the final PR. I do too. I will not be involved in producing the final PR and these were the conditions I agreed on. It's hard to find someone who will invest the time not knowing if all their work will carry through. I wish there were two steps in the RFC process. One voting for qualifying the idea/concept, and a second part to vote for the final PR. The first qualifying part could sort out the vast undesired ideas. And the second could attract coders and maybe allow for several PR proposals. Do the php team have any future intentions to maybe implement an RFC management system that could optimize both the creation, user experience, and voting process?
