Proposal for std.path replacement

Lars T. Kyllingstad public at kyllingen.NOSPAMnet
Fri Mar 4 01:11:23 PST 2011


On Thu, 03 Mar 2011 22:51:01 -0500, Nick Sabalausky wrote:

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

Thanks!


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

See my comments to Jonathan's post.


> - 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

I agree the names are terrible, and I like your suggestions.  I suggest 
we go with cmpPath, matchPath and matchPathChar.


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

I prefer "directory" over "dirName" too, but I can live with the latter.  
You'll have a hard time convincing me to use "directoryOf" or 
"dirNameOf", though. ;)


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

I hadn't thought of this, good thing you brought it up.  One thing which 
should perhaps be taken into consideration is that toCanonical() as it is 
now is a rather simple in-memory string operation.  expandTilde(), on the 
other hand, does disk I/O in some cases (it does a /etc/passwd lookup).  
I'll have to think some more about 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).

Good point.  It's definitely an absolute path, so I'll need to include 
this case in isAbsolute().  It is of course technically possible to set 
$HOME to a relative path, but it is quite pointless and not something we 
should worry about.


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

On POSIX you expect to be able to use ~ anywhere you're asked to input a 
path/filename.  Is this the case on Windows?  Can you write %HOMEDIR%
\report.doc in Word's "Open" dialog, for instance?


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

I agree a function that expands environment variables could be useful, 
but I don't think std.path is the right place for it.  Perhaps an 
"expand" member function of std.process.environment?


> That's all I can think of right now.

Thanks for the feedback!


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

:)

-Lars


More information about the Digitalmars-d mailing list