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 <[EMAIL PROTECTED]> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
![ftp://my.zip/dir1/*.jpeg"](ftp://my.zip/dir1/*.jpeg"){kind=link}