Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28221
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.184.238 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=DRO2U3L7E5o2OuqLPMajH8cMNRJ7C/4HS6H3BPxuaVANp1mX4WssJwreVqe0NtHuSwnoYjO7SoBlhE22dD9y1sGG1Ma0oTZZTJNx6VoGuzSLtqcSsEplSYkJ3tbIYY15lf5ddrpP5cfLR6CCh7WjljhNsKWFcTHi/p8gifJNpGI=
Message-ID: <fe05d1540703040922j3d146a5bw7b10009283e02a87@mail.gmail.com>
Date: Sun, 4 Mar 2007 18:22:03 +0100
To: "Marcus Boerger" <helly@php.net>
Cc: kingwez@gmail.com, "Arnold Daniels" <info@adaniels.nl>, 
	internals@lists.php.net
In-Reply-To: <592868326.20070304163838@marcus-boerger.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <45E33990.8030806@adaniels.nl>
	 <1331353216.20070226232944@marcus-boerger.de>
	 <45E37D05.5040000@adaniels.nl>
	 <408821909.20070303232323@marcus-boerger.de>
	 <fe05d1540703040446u201ce0b7we685bd50808e2c0c@mail.gmail.com>
	 <1508893792.20070304144812@marcus-boerger.de>
	 <fe05d1540703040629j21dc1442k4b2aee57f35d3ed3@mail.gmail.com>
	 <592868326.20070304163838@marcus-boerger.de>
Subject: Re: [PHP-DEV] suggestion SplFileInfo
From: pierre.php@gmail.com (Pierre)

To make this long story short, I do not understand the reason behind a
glob:// stream wrapper. It makes no sense. But yes, we need a better
glob support in PHP. Many extensions needs it. For example, I have my
own version for zip, it is bad as the only difference is how I get the
path string, the pattern implementation being 100% the same (using
pcre or bsd's glob)

On 3/4/07, Marcus Boerger <helly@php.net> wrote:

> >> > It may be more useful to add streams support to our glob functions.
> >> > But it can bring more troubles than expected.
>
> I did not elaborate on this really. So let me do that now. If we were
> going this way we would need to always overwrite the native glob
> implementation which we don't do right now. The reason being that we
> actually prefer to use the native implementation. Which should also be
> faster as a side effect.

You miss/drop my point, I don't like the glob:// wrapper addition. It
makes no sense as it has no meaning from a URI point of view.

To have the pattern matching functions (something like fnmatch for
example) always available and exported is indeed a good thing. Many
extensions can use it. That does not mean we cannot rely on the system
versions when available (for the local file operations at least).

>  Another thing is that doing so would only make
> the glob implementation itself profit from this. Providing the other way
> makes anything profit from glob support.

Correct me if I'm wrong but a Iterator+filter can do the same thing
without having this ugly glob://

$iter = new DirectoryIteratorPattern("/dir1/*.jpeg");
$iter = new DirectoryIteratorPattern("zip://my.zip/dir1/*.jpeg");
$iter = new DirectoryIteratorPattern("ftp://my.zip/dir1/*.jpeg");

Given that the stream wrapper provides the minimum set of ops to do it.

> We might even think of adding
> support for opening files through glob:// by having it open the first
> returned file when used for file opening.

I suppose we'll need other functions to move the cursor? Or make it
move forward magically on each fopen call? That's ugly.  ;-)

No other language implements blog or fnmatch support in such way but
using iterators and filters (in one form or another). Such magic
behaviors are always confusing.

> >> Actually the glob stream is exactly nothing else than streams layer
> >> for our glob functions.
>
> > Yes I saw that. That does not make a glob:// a good idea. In my humble
> > opinion, it fits better as filter for a iterator (simple loop or
> > whatever else like DirectoryIterator). I simply fail to see why the
> > stream must have this.
>
> In the same way as noted above a filter implementation would mean to
> have php come with an implementation of glob which we currently do not
> always have.

We always have it from 5.2.x and up. They are not exported in some
earlier versions, I'm not sure which versions have it exported or not.

> Damn, it apprears we have different taste :-)

It is not about taste. A glob is not a URI-like data. It is a filter.
I hope you understand my point now (for better glob support but no
glob://), let see what the other developers think about that.

--Pierre