Proposal for std.path replacement
Nick Sabalausky
a at a.a
Thu Mar 3 19:51:01 PST 2011
"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.
More information about the Digitalmars-d
mailing list