Next in Review Queue: The New std.path

Lars T. Kyllingstad public at kyllingen.NOSPAMnet
Fri Jul 15 14:26:15 PDT 2011


On Fri, 15 Jul 2011 15:42:50 -0400, Nick Sabalausky wrote:

> "Vladimir Panteleev" <vladimir at thecybershadow.net> wrote in message
> news:op.vyny7zfetuzx1w at cybershadow.mshome.net...
>> On Fri, 15 Jul 2011 03:20:13 +0300, dsimcha <dsimcha at yahoo.com> wrote:
>>
>>> Lars Kyllingstad's new and improved std.path module for Phobos is the
>>> next item up in the review queue.
>>
>> Three notes:
>> 1. No tests for extension("foo") is null && extension("foo.") !is null
> 
> I don't know if you're talking about actual unittests or documentation,
> but that brings up a good point: The behavior of extension("foo.")
> should be clearly documented. (Unless it already is and I just
> overlooked it?)

So what you guys are saying is, basically, that it matters whether a 
function returns null or ""?  I'd be inclined to say it doesn't, and 
leave it undefined, but I'd be interested in hearing good arguments 
against this.


>> 2. absolutePath's signature could be changed to string
>> absolutePath(string path, string base = getcwd()) for more flexibility
>> at no penalty 3. Would be nice to have relativePath(path, base) to
>> complement absolutePath().
>>
>>
> These two are absolutely (no pun intended) fantastic ideas. On #2,
> you're totally right about "more flexibility at no penalty". And
> relativePath() is necessary for converting a path into a relocatable
> form, which definitely has its uses especially when dealing with paths
> that will end up being used on other computers.

There is a penalty, albeit a small one, because it needs to be verified 
that isAbsolute(base).

-Lars


More information about the Digitalmars-d mailing list