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

[Nick Sabalausky]

"Lars T. Kyllingstad" <public at kyllingen.NOSPAMnet> wrote in message 
news:ikiht0$2vba$2 at 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.