Proposal for std.path replacement

[Lars T. Kyllingstad]

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