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