On 2011-07-18 11:25, Lars T. Kyllingstad wrote: > 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@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?
I suggest that you do what I did in std.file (e.g. with getTimesWin). I put this at the very top of the ddoc comment: $(BLUE This function is Windows-Only.) or if it's only on Posix: $(BLUE This function is Posix-Only.) - Jonathan M Davis