"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.) - 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). - Still some casing inconsistencies: basename, dirname, drivename still aren't camel-cased, but should be. - 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. - 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. Everything else about it looks great. 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.