On Tue, 01 Mar 2011 20:45:15 -0500, Nick Sabalausky wrote: > "Lars T. Kyllingstad" <public@kyllingen.NOSPAMnet> wrote in message > news:ikiht0$2vba$2...@digitalmars.com... >> >> 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. -Lars
