std.path review: second update

[Lars T. Kyllingstad]

On Mon, 01 Aug 2011 17:24:14 +0000, Jonathan M Davis wrote:

>> Here's a new update based on your comments and requests. Code and docs
>> are in the usual place,
>> [...]
> Well, my previous comments on function names still stand - both in terms
> of names using Ext instead of Extension and Sep instead of sep -

Since the feedback has been minimal since my last update, I take it 
people are more or less happy with the module's functionality now.  
(Unless they're just tired of the whole discussion, of course. ;)) 

That means it is time to let the bikeshedding begin.  Since we have been 
unable to reach a consensus in previous discussions, and there are now 
only three days left of the review, I would really like to get a good 
sample of the general opinion here.

Folks, please state your preferences in terms of function names.  I'll 
try to put personal bias aside and compose a naming scheme that is both 
internally consistent and consistent with the majority opinion.


> and also with regards to making non-property functions verbs (e.g.
> absolutePath and relativePath).

I'd be happy to change it, but I'm at loss for good alternatives.  I seem 
to remember you suggesting makeAbsolute and makeRelative, but not being 
100% happy with them yourself.  Any other suggestions?


> Aside from that, wasn't it discussed that extensions should include the
> . in them in order to cover the case where a file ends in a .? Otherwise
> 
> assert(extension("file.") == extension("file"));
> 
> So, all of the stuff dealing with extensions should probably include the
> dot in the extension. It looks like both the current std.path and your
> std.path handle it by using "" for dot and null for nothing, but
> distinguishing between null and the empty string like that isn't
> necessarily a good idea, and your documentation doesn't make the
> distinction clear, unlike the documentation for the current std.path.
> 
> So, at minimum, the docs should be clearer about null vs empty when it
> comes to the extension (and there should be tests for it), but it would
> arguably be better to just include the . in the extension.

I'm slowly coming around to the idea of including the dot.  Unless I hear 
any loud protests I will probably do so.

-Lars