Proposal for std.path replacement

[Jonathan M Davis]

> 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