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