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

[Lars T. Kyllingstad]

On Tue, 01 Mar 2011 20:45:15 -0500, Nick Sabalausky wrote:

> "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.)

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