Proposal for std.path replacement

[Bruno Medeiros]

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