Hi @Dan, hi @Sara. Thanks for giving us your feedback on this. > I think that although the RFC discussion can go ahead without a patch, > it would be better to have a patch before it went to vote, as there > seem to be quite a few hidden details that might not be able to be > made to work.
I wanted that too. But it's hard to find someone willing to invest the time and effort. And it's even harder when that time invested is not guaranteed to lead to something. Therefore a PoC patch was produced that should give a good understanding of what is intended. It was not my choice but I understood the reasons. > but as noted in the PR (https://github.com/php/php-src/issues/9224), > where cmb69 wrote: > > > > In some cases it just makes no sense (e.g. compress.zlib:// and data://), in some > > cases it is impossible (e.g. http://), and in some cases it still might be > > impractical (e.g. ftp://). > > The exact details of edge cases probably need to be at least listed as > people (well at least myself) would view a lack of those details as a > reason to vote 'no', even if they thought the general idea was good. > > The RFC probably also needs to make an argument of why something that > sounds like it would be a leaky abstraction should be in core (and so > generating more support requests) rather than people using the already > existing userland package > (https://packagist.org/packages/webmozart/glob) which currently has > over 10million installs. I don't know what you mean by "a leaky abstraction". If someone is proposing we should raise awareness of file operations with compress.zlib://, data://, ftp://, or http:// then that should be a discussion for all filesystem functions and not only glob(). scandir() for one already supports streamwrappers and I have no idea why somone would attempt scandir('http://')? The current error handling in glob() is returning an empty array if it fails. I wouldn't find it odd if it also did that for glob('http://'). Regarding webmozart's workaround. I don't see third party libraries as a reason why we can't have nice things on the core level. Rather the opposite. They tell me the efforts that were needed just to cover for something that wasn't available on the core level. And the vast amount of people who came across this limitation. > There's a PR linked, but we should define the actual goals/APIs etc... in the RFC itself as well as the numerous edge cases I agree. If you wanna put it in writing I can put it in the RFC. For the edge cases my proposal is to return that empty array like it does for any invalid path today. We could leave a note or tip in the documentation, but again then you might need to do so with scandir() and all the other filesystem functions. @Sara let me know if you would like to take over this RFC? You are more experienced than I am. /Tim
