On 03/03/2011 16:29, 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
I hope I'm not too late for the party, especially because I do have a
bit of criticism for this one...
Looking at the DDoc page, this module seem to have very
platform-dependent behavior. I find this detrimental, even unsavory. I
think it's best that programs work with internal data structures that
are as platform-independent as possible, and only convert to
platform-dependent data or API at the very last possible moment, when so
required (ie, when interfacing with the actual OS, or with the user).
So, with that in mind, there is a toCanonical function that converts to
a OS specific format, but there's no function to convert to an
OS/platform independent format?... :S
Also, what does dirName( "d:file") return on POSIX? Is it the same as on
Windows? I hope so, and that such behavior is explicitly part of the API
and not just accidental. (I don't a linux machine nearby to try it out
myself) Because, what if I want to refer to Windows paths from a POSIX
application? (I'm sure there are scenarios where that makes sense)
Or what if I just want my application to behave in a pedantically
platform-identical way, like having it to accept backlashes as path
separators not just on Windows but on POSIX as well? (This makes much
more sense than is immediately obvious... in many cases it can be argued
to be the Right Thing)
I'm sorry if I seem a bit agitated :P , it's just that due to some more
or less recent traumatizing events (a long story relating to Windows 7)
I have become a Crusader for cross-platformness.
The other suggestion I have (mentioned by others as well) is to
generalize the driver letter to a device symbol/string/identifier. But
this only makes sense if this device segment works in a
platform-independent way. This generalization might make the path module
useful in a few new contexts. Note, I'm not saying it should handle
URIs, in fact I want to explicitly say it should not handle URIs, as
URIs have additional semantics (query and fragment parts, the percent
encoding, etc.) which should not be of concern here.
BTW, I admit I take some inspiration from this API:
http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/runtime/IPath.html
Note that here there is only *one* platform dependent function, the
aptly named toOSString() ...
--
Bruno Medeiros - Software Engineer
