Proposal for std.path replacement

[Jonathan M Davis]

On Sunday 06 March 2011 03:56:53 Lars T. Kyllingstad wrote:
> On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote:
> > Looks good overall. I have a few comments and nitpicks though:
> >  >   basename("dir/subdir/")             -->  "subdir"
> >  >   directory("dir/subdir/")      -->  "dir"
> > 
> > Is this what everybody expects? I'm not sure, but another possibility
> > would be to treat these as if "dir/subdir/." is passed.
> 
> I don't know about everybody, but it is what *NIX users expect, at
> least.  I have written those functions so they adhere to the POSIX
> requirements for the 'basename' and 'dirname' commands.

If there's a standard way to deal with that, then that's probably best.

> > What is the
> > result of directory("/") or directory("d:/")?
> 
> "/" and "d:/", respectively.  The first is what 'dirname' prints, and the
> second is the natural extension to Windows paths.  (I believe I have
> covered most corner cases in the unittests.  I think it would just be
> confusing to add all of them to the documentation.)
> 
> >  >   extension("file")               -->  "" extension("file.ext")
> >  >   
> >  >       -->  "ext"
> > 
> > What about "file."? I tried it on NTFS, but trailing '.' seems to always
> > be cut off. Is it possible to create such a file on unix systems? If
> > yes, you won't be able to recreate it from the result of basename() and
> > extension().
> 
> Good point.  I don't know if there is any kind of precedent here.  What
> do others think?

I kind of like how your extension doesn't include the "." in it, since you'd 
often want to remove it anyway, but given this particular ambiguity, I think 
that it's probably better to go with the old way of including the "." in the 
extension.

- Jonathan M Davis