Next in Review Queue: The New std.path

[Nick Sabalausky]

"Lars T. Kyllingstad" <public at kyllingen.NOSPAMnet> wrote in message 
news:ivpnr5$gf5$7 at digitalmars.com...
> On Fri, 15 Jul 2011 04:33:34 -0400, Nick Sabalausky wrote:
>
>> - Maybe there should be a function canonical() that resolves symbolic
>> links, runs absolutePath() and normalize(), and on Windows converts to
>> lowercase. Doesn't need to be in there right now though, could wait for
>> a later release.
>
> I'd be more in favour of adding a resolveSymLinks function to std.file.
> In any case, I'd prefer it not be part of this proposal, and rather be
> added later.
>

Oh, yea, I didn't mean to imply that there shouldn't be a resolveSymLinks 
function. But I strongly believe that a function which combines all of that 
(and maybe the 8.3 -> full-name expansion on Windows, and maybe expansions 
of things like %APPDATA%) and guarantees a single unique canonical name for 
each actual (existing or non-existing) file would be a very, very, very good 
thing to have. Essenital, in fact, for comparing filepaths.

In any case, I agree that this can all wait until a later time and doesn't 
need to be in this proposal.

> I haven't done anything to glob (i.e. fnmatch in the current std.path)
> except change its name and improve its documentation.  For all intents
> and purposes, it is not part of my submission.  If I find the time,
> however, I'll look into improving it.
>

I see. In that case, maybe its name should remain fnmatch for now (or fnglob 
if you really want "glob" in there). That would prevent confuson both now 
and whenever it gets improved.