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

[Nick Sabalausky]

"Lars T. Kyllingstad" <public at kyllingen.NOSPAMnet> wrote in message 
news:ikl3m2$2i6s$1 at digitalmars.com...
> 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.
>

Hooray! That all sounds fantastic.