Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118653
MIME-Version: 1.0
References: <CAMrrT8_qMbfiaYp5PGfFxby7VQn3MVFNHZzjrKYPurK6apatPg@mail.gmail.com>
 <CAKxcST-Z6CJoJfacfb9hrZr6NKMFXvFQtaFZeE4GYHQN9uAr8A@mail.gmail.com> <CAESVnVrL8YweQAAnbjNMDGmXA9L0iXJ2Paw+B8tJjcV3-G=j6Q@mail.gmail.com>
In-Reply-To: <CAESVnVrL8YweQAAnbjNMDGmXA9L0iXJ2Paw+B8tJjcV3-G=j6Q@mail.gmail.com>
Date: Mon, 19 Sep 2022 00:01:44 +0200
Message-ID: <CAMrrT89FfGReZnJ0eQusxMZFCwTUzC0ftErHpzbDd0jxFMu=EQ@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000004b45f505e8fabe92"
Subject: Re: [PHP-DEV] RFC: StreamWrapper Support for glob()
From: timmy.almroth@gmail.com (Timmy Almroth)

--0000000000004b45f505e8fabe92
Content-Type: text/plain; charset="UTF-8"

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

--0000000000004b45f505e8fabe92--