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

[Lars T. Kyllingstad]

On Tue, 01 Mar 2011 02:37:27 -0800, Jonathan M Davis wrote:

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

It's definitely a work in progress, and therefore I'm not going to debate 
the naming scheme yet.  First I'll need to get the functionality in 
place. ;)

I would like to say, however, that I think 'sep' is almost up there with 
rel2abs in terms of bad naming.  If you just see 'sep' in a piece of 
code, maybe you understand it is a separator, but I don't think everyone 
will conclude it is a directory separator.  Using the fully qualified 
name 'std.path.sep' isn't good either, because now it looks like it's a 
path separator.

-Lars