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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
