On Sun, Sep 18, 2022 at 5:02 PM Timmy Almroth <timmy.almr...@gmail.com>
wrote:
>> 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.
>
I don't. I'm split too many ways atm to take on a PHP RFC.
I was using "we" in a more collective sense to mean "us as a project when
writing any RFC". The mechanics of wiring in a method in a wrapper to be
called as a proxy from a global function isn't hard. What's hard in this
case is defining what is expected from that function, specifically what a
typical user might expect. One might expect glob('https://www.php.net/*')
to return all names of all root pages on the site, and perhaps all short
aliases as well (which effectively includes all functions and classes).
There's no way a StreamWrapper implementation can accomplish that in the
general case, the protocol simply doesn't support it. But okay, we don't
implement it for http(s), but maybe we do got ftp(s), and might as well let
end users decide when they have a custom wrapper where it makes sense.
Cool. I'm just saying write all that out and put it in the RFC. There's
no need to know C or PHP's internal APIs to write that much. Write out the
API from the user's point of view, what assumptions you're making about
their use cases, and what risks are presented by cases like http(s) where
we won't be able to pull off a meaningful implementation.
-Sara
