On 3/4/07, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Sunday, March 4, 2007, 1:46:40 PM, you wrote:> On 3/3/07, Marcus Boerger <[EMAIL PROTECTED]> wrote: >> Hello Arnold, >> >> I added glob directory stream support. Now you can do two things: >> >> $d1 = new DirectoryIterator("glob://mydir/*"); >> $d2 = new DirectoryIterator("mydir/*", DirectoryIterator::USE_GLOB); >> >> count() stuff will follow. > I'm not sure it is a good idea to add glob:// stream support. What > does it have to do with custom streams? Will we add pcre:// too? If someone feels he needs pcre:// and can implement it why not.
Heck no :)
> DirectoryIteratorPattern/Glob($pattern) make much more sense to me. Feel free to implement it. Until you do so the problem is that DirectoryIterator uses streams directory support and cannot do anything else. Thus the onlyway to change the way it works is to provide other streams. And that is what I did. I chose to go the easy route which even might help other people.
It is maybe easy to add that (or pcre for that matter), does it make sense? It is not really a resource or custom protocol. Glob or pcre patterns (or any other patterns) are specific filters for a given URI/paths, but not resources specific paths like zip: file: or phar:.
> I did not test it but how does it work when used with other protocols? > like: ftp://some/path/? How is that going to work? Glob does not support that. But anyway, why not simply test it before complaining?
Can you please not see any comment on your commits or additions as complains? It is counter productive, annoying and brings nothing but anger.
> It may be more useful to add streams support to our glob functions. > But it can bring more troubles than expected. 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. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
