> On Wed, 06 Apr 2011 15:51:15 +0100, Bruno Medeiros wrote: > > 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 > > > > I hope I'm not too late for the party, especially because I do have a > > bit of criticism for this one... > > Not at all. Reviews of, and further work on, std.path has been put on > hold until I have handed in my PhD thesis (which, if all goes well, > should be very soon). I haven't got time to participate in any extensive > discussions on the NG right now. So there will be ample opportunity to > comment on the design yet. :) > > > 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() ... > > Thanks for the feedback, I will read it more thoroughly when I take up > work on std.path again. Just a general comment, though: Having the > exact same functionality on Windows and POSIX just doesn't work, if > nothing else simply because "c:\dir\file" is a valid base name on POSIX. > That is, both ':' and '\' are valid filename characters. The ONLY > invalid filename characters on POSIX are '/' and '\0'. > > Yes, weird file names like that may be uncommon, but the library should > be able to handle them nonetheless.
And on some file systems, even / is valid! Though it's not worth it to try and get std.path to work with files with / in the name. It's generally a very bad idea to create a file with a / in the name - too many programs would choke on it or just plain have the wrong behavior. However, there _are_ *nix file systems which allow for / in file names. - Jonathan M Davis