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