Neil Mitchell wrote:
I'm not sure about canonicalPath. This interface seems to suffer from
the same
race conditions as the temporary file interface: the answer is
immediately
invalid, so you can't rely on it.
The main purpose of canoncialPath is to fix the case on Windows, so
"c:\my documents\file.doc" becomes "C:\My Documents\file.doc" if that
is the case correct version of the file. I think this function will
not actually change the file with relation to the underying file
system, so should be race free. (I will document more to make the
operation clearer)
Right, as Krasimir pointed out we already have
System.Directory.canonicalizePath. Incedentally, this version removes "/../" in
a symlink-friendly way on Unix, because it uses realpath() underneath. It also
works with relative pathnames, prepending the current directory.
Then this seems inconsistent with the naming of splitFileName, which
should be splitFilePath.
No, since its splits a FilePath into a FileName and the rest left
over. In the same way that splitExtension takes a FilePath, but splits
into an extension. I have named the operations by the result, rather
than the input (which is almost always a FilePath)
It seems a bit odd because splitFileName follows the usual verb-noun convention,
but in this case the verb doesn't refer to the noun. Not all the oeprations are
named by the result: eg. dropFileName. That follows the verb-noun convention in
the normal way.
Isn't joinFilename the same as combine?
Yes, I hadn't spotted thats (the code is duplicated, and written in a
different style). However I feel its useful to have both of them in
there, since having the join/split duality is quite handy, and combine
"conceptually" operates on a lot more than just filenames.
I'd rather not have duplication because that can lead to confusion too - but at
least it should be clearly documented. Certainly we should not have all of
joinFileName, combine, addFileName
since they all do the same thing. Also,
getDirectory, dropFileName
do the same thing.
(btw, don't take all this as criticism, it's great that you're spending time on
this and I think it's worth sanding down the rough edges so we can incorporate
it in the base package).
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
