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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
