[Haskell-cafe] Re: ANN: System.FilePath 0.9

[Neil Mitchell]

Hi

> It's already there - see System.Directory.createDirectoryIfMIssing.
I'd missed that one entirely, and I think other people had (because I
added ensureDirectory at a request of several people), will go.

> If we have shortPath at all, perhaps it would be better named
> relativeToCurrentDIrectory?
Make sense, shortPath is not particularly well defined by name.

> 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)


> >>  We should avoid referring to $PATH as the "path", since we
> >> already have FilePath.
> >
> > Agreed, but I couldn't come up with a better name, if anyone has any
> > suggestions.
>
> "search path" seems the best option, I think.
Still has the Path in the name, which is the confusing bit, to me at least.


> > Has a FilePath of "/usr/bin/ghc" and a FileName of "ghc".
>
> 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)

> 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.


> get/setFilename are ok, but I prefer to reserve get/set for statelike things.
> Perhaps instead:
>
>    directoryOf :: FilePath -> String
>    filenameOf  :: FilePath -> String
>    extensionOf :: FilePath -> String
>    basenaneOf  :: FilePath -> String
>
>    replaceFilename  = joinFilePath . directoryOf
>    replaceDirectory = flip joinFilePath . filenameOf

I don't like directoryOf/replaceDirectory as names, since one has
Directory at the front and the other at the end. However I'm flexible
about this. Ideally I wanted to use the record constructors:

  mypath{directory = "value"}
  directory mypath.

Unfortunately that can't be done with FilePath = String, and even with
a separate constructor and records its not particularly nice to write.

> (unfortunately this use of basename is inconsistent with the Unix command,
> perhaps there's a better name?).
If anyone can think of one... Naming is not my strong point!

Thanks

Neil