std.path review: update

Jonathan M Davis jmdavisProg at gmx.com
Mon Jul 18 11:38:00 PDT 2011


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 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?

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


More information about the Digitalmars-d mailing list