Re: ANN: System.FilePath 0.10
Neil Mitchell wrote:
ANNOUNCEMENT:
I am hereby announcing System.FilePath 0.10, which hopefully is pretty close to final now. This library manipulates FilePath's correctly on both Posix and Windows.
http://www-users.cs.york.ac.uk/~ndm/projects/libraries.php#filepath
(Includes a darcs repo, a .tar.gz, haddock documentation etc)
In this version I have made reasonably large changes:
* Lots of functions gone (temporary file handling, canonicalization, drive manipulation, directory creation, directory enumeration) - pretty much down to only pure (non-IO methods) left.
* 3 new methods (asFile, isFile, asDirectory - look up the docs for their meanings, but they are pretty small)
* Renamed functions to follow the scheme replace/take/drop instead of set/get/drop - as suggested by Simon Marlow (since set/get implies state operations in Haskell)
Looks good! I have a few small further suggestions: - remove addFileName: it does the same thing as combine, or rather the difference is subtle and not mentioned in the docs. It's subsumed by combine, anyway. - remove isDirectory. I think its presence is confusing, e.g forall x. isDirectory (takeDirectory x) == False! Also it's not really correct; "/bin/" means something subtly different to "/bin" on Unix systems. Similarly isFile, asFile, asDirectory could be removed, I think. - Use the terminology "search path" consistently for anything to do with $PATH. i.e. fileSeparator => searchPathSeparator, isFileSeparator => isSearchPathSeparator, splitFiles => splitSearchPath also, move fileSeparator, isFileSeparator into the $PATH section in the docs (or change "basic functions" to "separator predicates"). - remove splitPath: splitDirectories is enough. I'd rename it to splitPathComponents, though. - shortPath => relativeToCurrentDirectory shortPathWith => makeRelativePath Cheers, Simon
Hi Simon,
- remove addFileName: it does the same thing as combine, or rather the difference is subtle and not mentioned in the docs. It's subsumed by combine, anyway.
The difference is subtle: System.FilePath> addFileName "test" "c:\\" "test\\c:\\" System.FilePath> combine "test" "c:\\" "c:\\" I'm coming around to the idea that addFileName is subtly different and entirely wrong, so yes, removing it seems fine.
- remove isDirectory. I think its presence is confusing, e.g forall x. isDirectory (takeDirectory x) == False! Also it's not really correct; "/bin/" means something subtly different to "/bin" on Unix systems. Similarly isFile, asFile, asDirectory could be removed, I think.
The reason I have them is because there are some circumstances where they are required in some programs. For example the behaviour of "cp" is different depending on whether the item is given as a file or a directory - hence these methods abstract away testing for that difference. I will think about this.
- Use the terminology "search path" consistently for anything to do with $PATH. i.e. fileSeparator => searchPathSeparator, isFileSeparator => isSearchPathSeparator, splitFiles => splitSearchPath
Ok, makes sense - I viewed it as a "collection of files", of which one instance is a search path. I guess in reality this will be the only "collection of files" so the name should reflect this.
also, move fileSeparator, isFileSeparator into the $PATH section in the docs (or change "basic functions" to "separator predicates").
Renaming basic functions to separator predicates is easy enough. I'd rather leave these predicates in a separate section so people are less inclined to use them - they are the building blocks that the higher level functionality is based on.
- remove splitPath: splitDirectories is enough. I'd rename it to splitPathComponents, though.
splitPath has the nice property that you can join it back together again with the right file separators: (\\ == \ since its escaped in a string) System.FilePath> joinPath $ splitPath "test/file\\more" "test/file\\more" System.FilePath> joinPath $ splitDirectories "test/file\\more" "test\\file\\more" This allows the developer to keep the FilePath more as the user specified. Maybe its not worth it though.
- shortPath => relativeToCurrentDirectory shortPathWith => makeRelativePath
I like them having the same prefix, it makes them more related in some way. makeRelative and makeRelativeToCurrentDirectory seem more natural to me. However, I'm not overly fussed. I've updated the way the versions of the FilePath library are organised, so once everyone's finished discussing this I'll try and get a 0.11 out in the next week that addresses these issues. Thanks Neil
participants (2)
-
Neil Mitchell -
Simon Marlow