Proposal for std.path replacement

[Nick Sabalausky]

"Lars T. Kyllingstad" <public at kyllingen.NOSPAMnet> wrote in message 
news:ikofkc$322$1 at digitalmars.com...
> As mentioned in the "std.path.getName(): Screwy by design?" thread, I
> started working on a rewrite of std.path a long time ago, but I got
> sidetracked by other things.  The recent discussion got me working on it
> again, and it turned out there wasn't that much left to be done.
>
> So here it is, please comment:
>
>    http://kyllingen.net/code/ltk/doc/path.html
>    https://github.com/kyllingstad/ltk/blob/master/ltk/path.d
>

I'm certainly all in favor of this (being the one that started the 
"std.path.getName(): Screwy by design?" thread in the first place ;) ). It's 
a huge improvement over the current std.path.

My (updated) comments:

Names:
- Given the choice between "*Separator" and "*Sep", I would lean towards 
"*Sep". But I'd be perfectly happy either way since I'll probably never use 
either of them (Like I said in the other thread, I'd rather just use 
forward-slash everywhere and convert to backslashes (probably via 
toCanonical) as-needed. So much less messy that way.)

- Regarding any other abbreviation like "extension" vs "ext" or "directory" 
vs "dir": I like them either way. It's all good.

- Need to change "basename" to "baseName". I'd actually be happier with 
"fileNameOf", but "baseName" is fine, too. No objection, as long as it's 
camel-cased.

- fcmp, fncharmatch and fnmatch are pretty awful names. If I just look at 
"fcmp" I can't tell what the hell the "f" means. Compare floating-point 
numbers? Doesn't remotely scream "compare file names".  The other two are 
worse: "fn" keeps telling my brain "function" every time I look at it even 
though I know full well I'm looking at std.path. I don't really care much 
about the exact final name, but as examples, anything along these lines 
would be good:
    fcmp -> cmpFileName
    fnmatch -> matchPath, matchGlob or maybe matchFileName
    fncharmatch -> matchPathChar, or maybe matchFileNameChar or 
matchFileChar

- Regarding "directory", I disagree with Jonathan that it sounds like it 
checks if it's a valid directory. I would *strongly expect* a function like 
that to be named "isDirectory" or "isDir". I'm happy with the name 
"directory" and prefer it to his suggestion of "dirName", *but* I would not 
object to "dirName" (as long as "drive" is changed to "driveName" for 
consistency). Something like "directoryOf" or "dirNameOf" might be even 
better still. I'd be happy with any of the above though.

Functionality:
- toCanonical needs to expand the tilde "~" path. If it already does, the 
docs should mention this.

The tilde needs to be thought out more:
- Is "~/foo" a relative path or absolute? Either way, it should be 
documented. If it's relative, then toAbsolute needs to expand it (and be 
documented as such).

- Maybe it should be "expandHomeDir" or "expandHome" instead of 
"expandTilde"?

- Windows *does* have a concept of a home dir, so maybe tilde should be 
expanded even on Windows. Only problem though is that Windows has *two* main 
home dirs for each user: %HOMEPATH% for user-created files and %APPDATA% for 
application data. (And some others, but I don't think any of the others are 
appropriate for "~") So maybe there should be these three:

        1. expandTilde: Exactly as it is now: expands ~ on posix, no-op on 
windows.

        2. expandHomeDir: On posix: Expands "~" and "%HOMEDIR%" to the 
user's home directory. On windows: Expands "~" and "%HOMEDIR%" to whatever 
%HOMEDIR% is set to.

        3. expandAppDataDir: On posix: Expands "~" and "%APPDATA%" to the 
user's home directory. On windows: Expands "~" and "%APPDATA%" to whatever 
%APPDATA% is set to.

- Speaking of %HOMEDIR% and %APPDIR%, there should be a function that 
expands all of these: 
http://technet.microsoft.com/en-us/library/cc749104(WS.10).aspx   Although I 
think those are all environment vars, so a function that just expands env 
vars might be good enough. Either way, it should definitely be called by 
toCanonical (and documented as such). Special thought would have to be given 
to how to handle this cross-platform. Maybe any ones with obvious 
equivalents on posix (like %HOMEDIR%, %APPDIR%, and %TEMP%) should be 
converted appropriately on posix. Maybe posix uses a different delimiter, 
and if so, how to handle the each delimiter on each platform should be 
thought out.

That's all I can think of right now.

Of course if your proposed module becomes the new std.path just as it is and 
the above improvements wait for another update, I'd still be happy. Heck, 
again, your module is a *huge* improvement over the current std.path even 
just as it is.