Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118659
MIME-Version: 1.0
References: <CAMrrT8_qMbfiaYp5PGfFxby7VQn3MVFNHZzjrKYPurK6apatPg@mail.gmail.com>
 <CAKxcST-Z6CJoJfacfb9hrZr6NKMFXvFQtaFZeE4GYHQN9uAr8A@mail.gmail.com>
 <CAESVnVrL8YweQAAnbjNMDGmXA9L0iXJ2Paw+B8tJjcV3-G=j6Q@mail.gmail.com>
 <CAMrrT89FfGReZnJ0eQusxMZFCwTUzC0ftErHpzbDd0jxFMu=EQ@mail.gmail.com> <CAESVnVrv5vK9sFUtSYxS8YZcioK0BCYiKVTo=urmDb7vjkNZMA@mail.gmail.com>
In-Reply-To: <CAESVnVrv5vK9sFUtSYxS8YZcioK0BCYiKVTo=urmDb7vjkNZMA@mail.gmail.com>
Date: Mon, 19 Sep 2022 18:45:35 +0200
Message-ID: <CAMrrT8__kQkEMq3f9MD4krsij+DGVpsBJvrYiPOsmqg5X9547g@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007debe605e90a7117"
Subject: Re: [PHP-DEV] RFC: StreamWrapper Support for glob()
From: timmy.almroth@gmail.com (Timmy Almroth)

--0000000000007debe605e90a7117
Content-Type: text/plain; charset="UTF-8"

> 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.
>

Whether a streamwrapper can be used with glob() or not is not a limitation
of the intended glob() implementation, but a limitation of the
StreamWrappers themselves. The problem already applies to scandir() today.
scandir('ftp://.../') would only resolve contents if the streamwrapper
supports it. Someone can substitute PHP's streamwrapper for ftp with one
that does resolve content. I'm not sure how many would attempt these border
cases, but the documentation could state some words of advice. We could
list what streamwrappers that work out of the box, or vice versa.

I would not change the way glob() returns data. For invalid paths or
streamwrappers it would just continue to return an empty array() like it
does today.

I edited the RFC to mention these edge cases and limitations. And how they
would be handled.
If you feel I missed something out I'm grateful if you wanna send a few
words fit for copy and pasting to the RFC.

/Tim

--0000000000007debe605e90a7117--