Hello Pierre,
Sunday, March 4, 2007, 6:22:03 PM, you wrote:
> 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)
So instead of discussing here you should take the glob code of win32
directory, check the license and either make otwork as you want or reqrite
it. Having that stuff in zip makes absolutely no sense at all. Especially
when it is already there. It is always better to reuse then to provide new
errors...
> 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.
Then don't use it.
> 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";);
It would be much slower. And still glob offers more. It works like your
system does.
> Given that the stream wrapper provides the minimum set of ops to do it.
What stream wrapper are we talking of now? The pcre filter stream you are
going to implement? The wrapper that is there right now is glob and yes,
that one provides the minimum that is needed.
>> 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. ;-)
Exactly, Hence glob only does what it can do.
> 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.
No other lanaguage has an Iterator implementation of the power PHP offers.
So shall we drop that? And guess what languages are different. For example
no other language has ternary implemented in the way PHP has.
>> 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.
Just in case you didn't notice. Glob is for directory listing. And the glob
stream does exactly that in a portable way that can easily be used form
anything that works on directories. Plain file directories that is because
glob does not understand anything. And should you work on it as described
above then anything using glob stream will automagically profit from that.
And this cooperation is the reason we have streams in the first place. If
you feel i left out zip - which is what your complain sounds like. Then I
suppose you go the route I laid down to solve that. It is not of my concern.
I for one did something that a user brought up, which made perfectly sense
to me and which already helped me. That is all I need to know.
Best regards,
Marcus
--
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}