Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » suggestion SplFileInfo »

suggestion SplFileInfo

php.internals

Arnold Daniels

19 years ago
Hi, I've got a few feature suggestions for SplFileInfo and DirectoryIteratorRecursive. I'm creating yet another php file manager. I've noticed that I needed to add quite some code to make it act the way gnome nautilus does. I believe these feature would be a good addition. SplFileInfo: - Add parameter $flags to constructor. The flags are passed to any fileinfo object created. - Add flags FOLLOW_LINK_ALWAYS, FOLLOW_LINK_EXISTS, FOLLOW_LINK_NEVER for the constructor. Functions as getPerms and getOwner will look at this setting. - Add getBasename, to get the basename of either a dir or file. - Function getLinkTarget, does readlink($this->getPathname()) - Function getRealpath, does realpath($this->getPathname()) - Function getOwnerName and getGroupName - Function isHidden, to check wether a file is hidden - Functions getTypeInfo and getMime, to get info of the file using libmagic - Function setDirInfoClass, set a info class specially for directories DirectoryIteratorRecursive: - Add flag DIRS_ONLY for the constructor, to only loop through directories - Add flag WITHOUT_HIDDEN_FILES for the constructor, not to loop through hidden files - Function getFileCount If you like these features, but don't have time to implement them, I can see if I can write a patch. I'm quite new at writing PHP extensions, but I know the basics. Best regards, Arnolds

Marcus Börger

19 years ago
Hello Arnold, some interesting ideas indeed. See my comments below. best regards marcus Monday, February 26, 2007, 8:48:32 PM, you wrote:
> Hi,
> I've got a few feature suggestions for SplFileInfo and > DirectoryIteratorRecursive. I'm creating yet another php file manager. > I've noticed that I needed to add quite some code to make it act the way > gnome nautilus does. I believe these feature would be a good addition.
> SplFileInfo: > - Add parameter $flags to constructor. The flags are passed to any > fileinfo object created.
In case we need flags this will be added to the constructor or as seperate getter/setter. My preference is actually the latter.
> - Add flags FOLLOW_LINK_ALWAYS, FOLLOW_LINK_EXISTS, FOLLOW_LINK_NEVER > for the constructor. Functions as getPerms and getOwner will look at > this setting.
I will need to check whether I Can do that. If so I will add flags as well. Until then you can overwrite hasChildren() to return "parent::hasChildren() && !this->isLink()" to solve the third flag. The second flag also needs to verify the target by using getLinkTarget() (see below). Finally the first flag is simplywhat we have right now.
> - Add getBasename, to get the basename of either a dir or file. > - Function getLinkTarget, does readlink($this->getPathname())
added in HEAD as getLinkTarget()
> - Function getRealpath, does realpath($this->getPathname())
added in HEAD as getRealPath()
> - Function getOwnerName and getGroupName
Use posix_getpwuid() and posix_getgrgid() *if available*. I prefer not to have them in SPL.
> - Function isHidden, to check wether a file is hidden
I don't think we have support for windows' hidden flag, do we? Under *nix as I just reminded you can simply check whether thefilename starts with a dot.
> - Functions getTypeInfo and getMime, to get info of the file using libmagic
there are getType and getMTime, that should be enough no?
> - Function setDirInfoClass, set a info class specially for directories
What I could do is providing a slow mechanism that actually does a stat call and checks the dir flag. Then internally add a pointer for the directory info class and a getter/setter for that. It would be initialized to null and thegetter would see the normal info class as long as it is null. That way the directory info is bound to the standard info class until you explicitly split it. Would this solve your problem? Maybe for PHP 5.3 there should be a stat cache tospeeed things up.
> DirectoryIteratorRecursive: > - Add flag DIRS_ONLY for the constructor, to only loop through directories
This is achieved by a FilterIterator: ParentIterator
> - Add flag WITHOUT_HIDDEN_FILES for the constructor, not to loop > through hidden files
Can be done easily by providing a filter.
> - Function getFileCount
That would require to loop through the directory which is not what we want. If you need the count after usingthe elements you can for example loop through a CachingIterator which ha sa newly introduced count method that will give you the number of elements used.
> If you like these features, but don't have time to implement them, I can > see if I can write a patch. I'm quite new at writing PHP extensions, but > I know the basics.
> Best regards, > Arnolds
Best regards, Marcus

Arnold Daniels

19 years ago
Hi again, Thanks for your response. I've put some new comments below. Marcus Boerger wrote:
> Hello Arnold, > > some interesting ideas indeed. See my comments below. > > best regards > marcus > > Monday, February 26, 2007, 8:48:32 PM, you wrote: > > >> Hi, >> > > >> I've got a few feature suggestions for SplFileInfo and >> DirectoryIteratorRecursive. I'm creating yet another php file manager. >> I've noticed that I needed to add quite some code to make it act the way >> gnome nautilus does. I believe these feature would be a good addition. >> > > >> SplFileInfo: >> - Add parameter $flags to constructor. The flags are passed to any >> fileinfo object created. >> > In case we need flags this will be added to the constructor or as > seperate getter/setter. My preference is actually the latter. >
Sure that works just as well, but it would be useful if the flags are passed down. That way you can also use it on a DirectoryIterator.
> >> - Add flags FOLLOW_LINK_ALWAYS, FOLLOW_LINK_EXISTS, FOLLOW_LINK_NEVER >> for the constructor. Functions as getPerms and getOwner will look at >> this setting. >> > I will need to check whether I Can do that. If so I will add flags as well. > Until then you can overwrite hasChildren() to return "parent::hasChildren() > && !this->isLink()" to solve the third flag. The second flag also needs to > verify the target by using getLinkTarget() (see below). Finally the first > flag is simplywhat we have right now
I believe that there is a bit of miscommunication here. The flags should determine if stat or lstat is used to get the properties of the files. Currently spl always uses stat. Perhaps the names I came up with aren't perfect.
> . > > >> - Add getBasename, to get the basename of either a dir or file. >>
Did you overlook this? or don't you like it.
>> - Function getLinkTarget, does readlink($this->getPathname()) >> > added in HEAD as getLinkTarget() >
Perfect
> >> - Function getRealpath, does realpath($this->getPathname()) >> > added in HEAD as getRealPath() >
Excellent
> >> - Function getOwnerName and getGroupName >> > Use posix_getpwuid() and posix_getgrgid() *if available*. I prefer not to > have them in SPL. >
Ok very well
> >> - Function isHidden, to check wether a file is hidden >> > I don't think we have support for windows' hidden flag, do we? Under > *nix as I just reminded you can simply check whether thefilename starts > with a dot. >
Yes that true, but it would be nice to have a function which returns a boolean and work for both windows and unix. Perhaps a workaround can be thought off for windows.
> >> - Functions getTypeInfo and getMime, to get info of the file using libmagic >> > there are getType and getMTime, that should be enough no? >
No the name are almost the same, but the output isn't. I'm talking about integrating the features provided by fileinfo (http://www.php.net/fileinfo). Perhaps the names aren't chosen well.
> >> - Function setDirInfoClass, set a info class specially for directories >> > What I could do is providing a slow mechanism that actually does a stat > call and checks the dir flag. Then internally add a pointer for the > directory info class and a getter/setter for that. It would be initialized > to null and thegetter would see the normal info class as long as it is > null. That way the directory info is bound to the standard info class > until you explicitly split it. Would this solve your problem? > > Maybe for PHP 5.3 there should be a stat cache tospeeed things up. >
Yes that would be perfect. PS. Currently looping with a DirectoryIterator returns a DirectoryIterator for each child, dirs as well as files, instead of the class set using setInfoClass(). Is this correct? It wasn't what I expected. RecursiveDirectoryIterator work like I expected.
> >> DirectoryIteratorRecursive: >> - Add flag DIRS_ONLY for the constructor, to only loop through directories >> > This is achieved by a FilterIterator: ParentIterator >
Yes but if you want to loop recursively through the directories, creating an object for each file gives a huge overhead. Glob has a directory only flag, may that feature can be used.
> >> - Add flag WITHOUT_HIDDEN_FILES for the constructor, not to loop >> through hidden files >> > Can be done easily by providing a filter. >
Ok that is fine.
> >> - Function getFileCount >> > That would require to loop through the directory which is not what we want. > If you need the count after usingthe elements you can for example loop > through a CachingIterator which ha sa newly introduced count method that > will give you the number of elements used. >
Isn't there a way you can easily get this information from the system? Anyhow I much rather have a loop in c through a set of filenames, than looping in php using the iterator. I believe having the ability to give the number of files of a directory is really useful, even if you don't want to do anything with the files from the dir. For example: gnome nautilus displays the number files for each dir instead of the filesize.
> >> If you like these features, but don't have time to implement them, I can >> see if I can write a patch. I'm quite new at writing PHP extensions, but >> I know the basics. >>
Thanks again. If you need any help, please let me know. Best regards, Arnold

LAUPRETRE François (P)

19 years ago
> From: Arnold Daniels [mailto:info@adaniels.nl]
> >> DirectoryIteratorRecursive: > >> - Add flag DIRS_ONLY for the constructor, to only loop through > >> directories > >> > > This is achieved by a FilterIterator: ParentIterator > > > Yes but if you want to loop recursively through the directories, > creating an object for each file gives a huge overhead. Glob has a > directory only flag, may that feature can be used.
One more argument for a PHP internal implementation of glob()/fnmatch(), as GLOB_ONLYDIR is not portable (probably not posix-compliant). We could also add a flag to exclude broken symbolic links, and globbing support in stream wrappers (would allow a syntax like wget's 'ftp://dir/*'). I have written a feature request listing glob()-related problems 6 months ago (http://bugs.php.net/bug.php?id=38022). If somebody is interested, it could be time to reactivate it (unfortunately, I won't have enough free time to work on it). Regards Francois

Marcus Börger

19 years ago
Hello Arnold, a bunch of new stuff based on your suggestions will be added to 5.2.2. I also added more comments below. Tuesday, February 27, 2007, 1:36:21 AM, you wrote:
> Thanks for your response. I've put some new comments below.
>>> SplFileInfo: >>> - Add parameter $flags to constructor. The flags are passed to any >>> fileinfo object created. >> In case we need flags this will be added to the constructor or as >> seperate getter/setter. My preference is actually the latter. > Sure that works just as well, but it would be useful if the flags are > passed down. That way you can also use it on a DirectoryIterator.
DirectoryIterator extends SplFileInfo, so it would work just fine.
>>> - Add flags FOLLOW_LINK_ALWAYS, FOLLOW_LINK_EXISTS, FOLLOW_LINK_NEVER >>> for the constructor. Functions as getPerms and getOwner will look at >>> this setting. >> I will need to check whether I Can do that. If so I will add flags as well. >> Until then you can overwrite hasChildren() to return "parent::hasChildren() >> && !this->isLink()" to solve the third flag. The second flag also needs to >> verify the target by using getLinkTarget() (see below). Finally the first >> flag is simplywhat we have right now > I believe that there is a bit of miscommunication here. The flags should > determine if stat or lstat is used to get the properties of the files. > Currently spl always uses stat. Perhaps the names I came up with aren't > perfect.
That makes more sense then. However we need to have isLink() operate on stat always and not have it suddenly operate on the link target. The problem here however is that we need to extend streams api so it supports lstat. Right now it doesn't.
>>> - Add getBasename, to get the basename of either a dir or file. > Did you overlook this? or don't you like it.
Oops....added that as well now.
>>> - Function isHidden, to check wether a file is hidden >> I don't think we have support for windows' hidden flag, do we? Under >> *nix as I just reminded you can simply check whether thefilename starts >> with a dot. > Yes that true, but it would be nice to have a function which returns a > boolean and work for both windows and unix. Perhaps a workaround can be > thought off for windows.
Right now the underlying api's have absolutely no support for windows file attributes. So we'd need to add a lot of stuff. Which won't happen. So the only thing we can do is adding isHidden for non windows where we would simply check for first char being '.'.
>>> - Functions getTypeInfo and getMime, to get info of the file using libmagic >> there are getType and getMTime, that should be enough no? > No the name are almost the same, but the output isn't. I'm talking about > integrating the features provided by fileinfo > (http://www.php.net/fileinfo). Perhaps the names aren't chosen well.
If we ever have fileinfo as a core component to php which cannot be disabled you should remind me again. Until then it should be a user solution like with the posix stuff for getting owner/group name.
>>> - Function setDirInfoClass, set a info class specially for directories >> What I could do is providing a slow mechanism that actually does a stat >> call and checks the dir flag. Then internally add a pointer for the >> directory info class and a getter/setter for that. It would be initialized >> to null and thegetter would see the normal info class as long as it is >> null. That way the directory info is bound to the standard info class >> until you explicitly split it. Would this solve your problem? >> Maybe for PHP 5.3 there should be a stat cache to speeed things up. > Yes that would be perfect. > PS. Currently looping with a DirectoryIterator returns a > DirectoryIterator for each child, dirs as well as files, instead of the > class set using setInfoClass(). Is this correct? It wasn't what I > expected. RecursiveDirectoryIterator work like I expected.
DirectoryIterator is much easier then the recursive one. That way it is faster but cannot do all the recursive one can do.
>>> DirectoryIteratorRecursive: >>> - Add flag DIRS_ONLY for the constructor, to only loop through directories >> This is achieved by a FilterIterator: ParentIterator > Yes but if you want to loop recursively through the directories, > creating an object for each file gives a huge overhead. Glob has a > directory only flag, may that feature can be used.
Problem is we don't use glob here. The advantage of using streams is also direclty its disadvantage. Streams directory functionality works for anythign that can be treated as a directory. But only in forward mode. The way out would be to provide a new glob stream. For instance: $dir = new DirectoryIterator("glob//:~/*.php"); Only problem here is where to put the flags.
>>> - Function getFileCount >> That would require to loop through the directory which is not what we want. >> If you need the count after usingthe elements you can for example loop >> through a CachingIterator which ha sa newly introduced count method that >> will give you the number of elements used. > Isn't there a way you can easily get this information from the system? > Anyhow I much rather have a loop in c through a set of filenames, than > looping in php using the iterator. I believe having the ability to give > the number of files of a directory is really useful, even if you don't > want to do anything with the files from the dir. For example: gnome > nautilus displays the number files for each dir instead of the filesize.
If the glob stream was provided this would work. For non glob input it would throw an exception then. Best regards, Marcus

Marcus Börger

19 years ago
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. Best regards, Marcus

Pierre Joye

19 years ago
On 3/3/07, Marcus Boerger <helly@php.net> 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? DirectoryIteratorPattern/Glob($pattern) make much more sense to me. I did not test it but how does it work when used with other protocols? like: ftp://some/path/? It may be more useful to add streams support to our glob functions. But it can bring more troubles than expected. --Pierre

Marcus Börger

19 years ago
Hello Pierre, Sunday, March 4, 2007, 1:46:40 PM, you wrote:
> On 3/3/07, Marcus Boerger <helly@php.net> 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.
> 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.
> 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?
> 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. Best regards, Marcus

Pierre Joye

19 years ago
On 3/4/07, Marcus Boerger <helly@php.net> wrote:
> Sunday, March 4, 2007, 1:46:40 PM, you wrote: > > > On 3/3/07, Marcus Boerger <helly@php.net> 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

Marcus Börger

19 years ago
Hello Pierre, Sunday, March 4, 2007, 3:29:06 PM, you 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. 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. 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.
>> 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. Damn, it apprears we have different taste :-) Best regards, Marcus

Pierre Joye

19 years ago
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

Marcus Börger

19 years ago
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

LAUPRETRE François (P)

19 years ago
> From: Pierre [mailto:pierre.php@gmail.com] > > 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.
I agree. PHP glob() needs to be rewritten to call a glob() hook in stream wrappers. And only the 'plain file' wrapper would then call the OS native glob(). Other stream wrappers like zip:, phar:, or phk: would provide their own implementations (provided they can use a reliable fnmatch()).
> I will take another way to understand why one can add URI wrappers in the core stream > implementation without discussing it and even worst, without allowing any discussion about > his choice.
Agree again. François