std.path review: second update

[Nick Sabalausky]

"Lars T. Kyllingstad" <public at kyllingen.NOSPAMnet> wrote in message 
news:j16pv5$id8$3 at digitalmars.com...
>
> 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.
>

I'm happy either way with Sep/Ext or Separator/Extension. I guess my 
preference would be for the shorter versions. They're perfectly clear (who 
isn't familiar with the "ext" abbreviation for "extension"?) and they're 
easier to spell. And one-line file/path manipulations are less likely to 
grow too far past the 80-char mark. But if we kept the long ones, I wouldn't 
complain.

>
>> 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 agree with "function names should be verbs" as a general guideline, but I 
don't think it should be taken so strictly that it gets forced on in 
situations (like this one) where it just doesn't work quite as well. Despite 
not being verbs, "absolutePath/relativePath" are perfectly clear and much 
more descriptive than "makeAbsolute/makeRelative" (Make an absolute or 
relative what?). And then "makeAbsolutePath/makeRelativePath" is just 
starting to get verbose.

I think this is one case where it's just not worthwhile to force the 
"function names should be verbs" guideline.

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

Sounds good to me.