std.path review: second update

[Jonathan M Davis]

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

If you want much feedback, you're probably going to need a new thread for 
that. I think that most people looked at the initial std.path implementation 
that you gave, had their say, and moved on. It wouldn't entirely surprise me 
if you could get away with making some incredibly stupid changes and then get 
them merged into Phobos simply because next to no one really looked at your 
most recent changes (I would hope that you wouldn't do that though).

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

I'd just go with makeAbsolute and makeRelative. Maybe makeAbolutePath and 
makeRelativePath (or makeAbsPath and makeRelPath) would be better, but those 
are getting a bit long.

It's defaultExtension which is problematic (aside from the fact that I think 
that Extension should be shortened to Ext). What it's trying to do is set the 
extension with a default extension if one isn't set but do nothing if it is, 
and I can't think of a good name for that. setExtToDefaultIfNoExt just doesn't 
roll off the tongue. ;)

So, I don't have a good fix for defaultExtension, but I think that going with 
makeAbsolute and makeRelative would be better, since they _do_ make sense and 
are proper verbs.

- Jonathan M Davis