"Lars T. Kyllingstad" <[email protected]> wrote in message news:[email protected]... > On Tue, 01 Mar 2011 20:45:15 -0500, Nick Sabalausky wrote: > >> "Lars T. Kyllingstad" <[email protected]> wrote in message >> news:[email protected]... >>> >>> 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 >>> >>> >> Just took a look at the doc page. I know it's not finished, but my >> comments based on how it is ATM: >> >> - toCanonical is something that std.path desperately needs. Without it, >> it's impossible to compare paths. I found the lack of it to be a big >> pain when I switched from Tango to Phobos2. >> >> - Like I've said in other posts, I strongly believe that if posix >> considers ".foo" to be an extensionless file named ".foo", then it >> should definitely be treated the *same way* on windows too, since the >> only times windows ever has such files is things like ".htaccess" or >> ".svn" that are already born of unix anyway. (Optlink's stray ".exe" >> junk files notwithstanding.) > > I agree. I changed this yesterday, and now it does the same on Windows > and POSIX. > > >> - Not sure what the point of currentDirSymbol and parentDirSymbol would >> be. But it's not as if their existence hurts anything. And I honestly >> don't care what sep/dirSeparator/etc is named (I'd just avoid using it >> in favor of / anyway. Yea, there may be some places in Windows where you >> need backslashes, but those should be wrapped in functions that convert >> to backslashes at the last minute as-needed. It shouldn't be allowed to >> obfuscate/infect the rest of the code). > > Actually, in my experience, all of the strings defined at the top of > std.path are next to useless. Most of the time I need to check "is this > character a dir separator?", and then I have to do > > if (path[i] == sep[0] || path[i] == altsep[0]) ... > > So I wrote an isDirSeparator() function that performs these tests, and > I've ended up using that almost exclusively. The only place I expect to > be using the predefined strings is in the join() function. > > >> - Still some casing inconsistencies: basename, dirname, drivename still >> aren't camel-cased, but should be. > > I know. The naming scheme is by no means set in stone, I'm saving that > for last. > > >> - It needs a function to remove the extension (while keeping the >> filename *and* path). Basically, it needs something that's akin to >> std.path.getName(), but actually works right. > > I added stripExtension(), setExtension() and defaultExtension() > yesterday. Haven't pushed anything to GitHub yet, though. > > >> - An admittedly minor issue, but the name of std.path.join() always >> bugged me because of the conflict with std.array.join(). I know D's >> module system is designed to handle exactly this kind of thing fine, and >> normally I find D's handling of it perfectly acceptable (except that it >> destroys universal member call syntax, but that's not really useful for >> join() anyway). But std.array.join() is such a commonly-useful thing, >> that it seems a bit much to require all uses of it to become >> fully-qualified as soon as std.path gets imported. Plus, even if >> std.array isn't imported, join(somePathVar, anotherPathVar) doesn't >> exactly scream "yes, this actually *is* correct". I think pathJoin(), >> joinPaths(), dirJoin() etc are perfectly good names that neatly sidestep >> all of those issues. > > I agree. > > >> Everything else about it looks great. > > Thanks! :) > > >> Overall, I'd love to see that module finished and used as the new >> std.path. The current std.path makes me REALLY nervous and I'm getting >> tired of tip-toeing my way through it. > > Well, this discussion got me working on it again, and I discovered there > isn't that much left to do. I expect it to be done relatively soon. >
Hooray! That all sounds fantastic.
