std.path review: update

[Lars T. Kyllingstad]

On Mon, 18 Jul 2011 13:16:29 -0400, Steven Schveighoffer wrote:

> On Sun, 17 Jul 2011 17:27:41 -0400, Lars T. Kyllingstad
> <public at kyllingen.nospamnet> wrote:
> 
>> Based on your comments, I have made some changes to my std.path
>> proposal.  A list of the changes I have made can be found at the
>> following address (look at the commits dated 2011-07-17):
>>
>>   https://github.com/kyllingstad/phobos/commits/std-path
> 
> This is a review of the docs/design.  I'll review the code separately:
> 
> basename's standards section says:
> 
> (with suitable adaptions for Windows paths)
> 
> adaptions => adaptations

Oops.  Thanks!

 
> This occurs twice.

Copy+paste. :)

 
> In driveName:
> 
> Should std.path handle uunc paths?  i.e. \\servername\share\path  (I
> think if it does, it should specify \\servername\share as the drive)

Yes, std.path is supposed to support UNC paths.  For instance, the 
following works now:

  assert (equal(pathSplitter(`\\foo\bar\baz`), [`\\foo`, "bar", "baz"]));

I guess you would rather have that

  assert (equal(pathSplitter(`\\foo\bar\baz`), [`\\foo\bar`, "baz"]));

then?  I am not very familiar with Windows network shares; is \\foo never 
a valid path on its own?

As I understand it, some POSIX systems also mount network drives using 
similar paths.  Does anyone know whether "//foo" is a valid path on these 
systems, or does it have to bee "//foo/bar"?


> joinPath:
> 
> Does this normalize the paths?  For example:
> 
> joinPath("/home/steves", "../lars") => /home/steves/../lars or
> /home/lars ?
> 
> If so, the docs should reflect that.  If not, maybe it should :)  If it
> doesn't, at least the docs should state that it doesn't.

No, it doesn't, and I don't think it should.  It is better to let the 
user choose whether they want the overhead of normalization by calling 
normalize() explicitly.  I will specify this in the docs.


> pathSplitter:
> 
> I think this should be a bi-directional range (no technical limitation I
> can think of).

It is more of a complexity vs. benefit thing, but as you are the second 
person to ask for this, I will look into it.  A convincing use case would 
be nice, though. :)


> fcmp:
> "On Windows, fcmp is an alias for std.string.icmp, which yields a case
> insensitive comparison. On POSIX, it is an alias for std.algorithm.cmp,
> i.e. a case sensitive comparison."
> 
> What about comparing c:/foo with c:\foo?  This isn't going to be equal
> with icmp.

I am a bit unsure what to do about the comparison functions (fcmp, 
pathCharMatch and globMatch).  Aside from the issue with directory 
separators it is, as was pointed out by someone else, entirely possible 
to mount case-sensitive file systems on Windows and case-insensitive file 
systems on POSIX.  (The latter is not uncommon on OSX, I believe.)  I am 
open to suggestions.


> expandTilde:
> 
> I've commented on expandTilde from the other posts, but if it is kept a
> posix-only function, the documentation should reflect that.

It does; look at the "Returns" section.  Perhaps it should be moved to a 
more prominent location?

-Lars