std.path.getName(): Screwy by design?

[Jonathan M Davis]

On Tuesday 01 March 2011 02:30:56 Lars T. Kyllingstad wrote:
> On Tue, 01 Mar 2011 03:58:04 -0500, Nick Sabalausky wrote:
> > According to the docs, std.path.getName() "Returns the extensionless
> > version of a filename or path."
> > 
> > But the doc also says that if the filename doesn't have a dot, then it
> > returns null (and I've verified that on DMD 2.050). Isn't that a bit
> > ridiculous? Shouldn't it still return the extensionless version even if
> > it doesn't have an extension? Ie, return the original string.
> > 
> > I would expect all of the following to pass, but currently (by design)
> > only the first two pass:
> > 
> > assert(getName(r"file.ext") == r"file");
> > assert(getName(r"/path/file.ext") == r"/path/file");
> > 
> > assert(getName(r"file") == r"file");
> > assert(getName(r"/path/file") == r"/path/file");
> > 
> > The current behavior seems useless.
> > 
> > Additionally, this also seems screwy:
> > 
> > // Currently passes:
> > assert(getName(r"/pa.th/file") == r"/pa");
> > 
> > WTF? The docs seem to suggest that's by design, but I can't imagine why.
> > Even on Windows it's not as if filenames can contain forward slashes
> > (and except for the command-line, accessing paths with forward-slash
> > separators works fine on Windows).
> > 
> > Fortunately, the docs do seem to be wrong about this:
> > 
> > version(Windows)
> > 
> >      getName(r"d:\path.two\bar") => null
> > 
> > That currently returns r"d:\path.two\bar" as I would expect.
> > 
> > If those in charge agree with me on all of the this, I'd be glad to go
> > through std.path, fix all of that, check for any other issues and submit
> > a modified std.path with updated examples and unittests for approval.
> 
> I've also found a few cases like that.  In general, I think std.path
> takes the KISS approach, probably because it's the most efficient and
> works in most cases, but I'd rather it did the Right Thing (TM) that
> works in all cases.
> 
> Searching for the "extension dot" is one such case.  The simplest thing
> is of course to search for a '.' character.  std.path does that, and also
> stops (I hope) at a dir separator.  However, it doesn't take into account
> the fact that Windows has two types of dir separator, nor that a dir
> separator immediately followed by a dot denotes a hidden file on POSIX.
> 
> Another problem with std.path is the horribly inconsistent naming
> scheme.  I mean, rel2abs?  Come on!
> 
> A while ago I started working on a rewrite of std.path, but it's only
> halfway done because I got derailed by other things.  Perhaps it's time
> to pick up on it again?
> 
>   http://kyllingen.net/code/ltk/doc/path.html
>   https://github.com/kyllingstad/ltk/blob/master/ltk/path.d

Obviously it's a work in process and not something that you're looking to have 
reviewed at the moment, but I'd point out that if you're reworking std.path like 
that, you should really make sure that the function names are properly 
camelcased. And I honestly prefer sep to dirSeparator, since it's a lot shorter. 
But given that you have pathSeparator, I guess that that makes sense (though 
perhaps both should be shorted to end in Sep). In any case, if you want to 
rework std.path a bit, I certainly have no problem with it. Overall, std.path is 
fairly good, but it does have some rough corners.

- Jonathan M Davis