Looks good overall. I have a few comments and nitpicks though:
> basename("dir/subdir/") --> "subdir"
> directory("dir/subdir/") --> "dir"
Is this what everybody expects? I'm not sure, but another possibility
would be to treat these as if "dir/subdir/." is passed. What is the
result of directory("/") or directory("d:/")?
> extension("file") --> ""
> extension("file.ext") --> "ext"
What about "file."? I tried it on NTFS, but trailing '.' seems to always
be cut off. Is it possible to create such a file on unix systems? If
yes, you won't be able to recreate it from the result of basename() and
extension().
What about network shares like "\\server\share\dir\file"? Maybe it
should also be shown in the examples? Does the "\\server" part need
special consideration?
Rainer
Lars T. Kyllingstad wrote:
As mentioned in the "std.path.getName(): Screwy by design?" thread, I
started working on a rewrite of std.path a long time ago, but I got
sidetracked by other things. The recent discussion got me working on it
again, and it turned out there wasn't that much left to be done.
So here it is, please comment:
http://kyllingen.net/code/ltk/doc/path.html
https://github.com/kyllingstad/ltk/blob/master/ltk/path.d
Features:
- Most functions work with all string types, i.e. all permutations of
mutable/const/immutable(char/wchar/dchar)[]. Notable exceptions are
toAbsolute() and toCanonical, because they rely on std.file.getcwd()
which returns an immutable(char)[].
- Correct behaviour in corner cases that aren't covered by the current
std.path. See the other thread for some examples, or take a look at the
unittests for a more complete picture.
- Saner naming scheme. (Still not set in stone, of course.)
-Lars
