std.path review: second update

[Jonathan M Davis]

On Wednesday 03 August 2011 08:35:10 Lars T. Kyllingstad wrote:
> On Mon, 01 Aug 2011 18:18:39 -0400, Nick Sabalausky wrote:
> > "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.
> 
> If I rename setExtension() and defaultExtension() to setExt() and
> defaultExt(), I feel like extension() should also be renamed to ext() for
> consistency's sake.  I would *really* dislike that, hence my resistance
> to the shorter names.

Well, it _is_ somewhat less consistent that way, but I think that gain in 
having shorter function names makes it worth it. So, I'd stick with extension 
but shorten all of the others to Ext. It _is_ consistent insomuch as all of 
the functions which have more than one word in them shorten it to Ext. The 
only odd man out is the one which is only one word, and I think that the 
reason why it was different would be fairly obvious to anyone using std.path.

So, yes. You have less consistency with setExt, defaultExt, and extension, but 
I definitely think that the benefits make it worth it.

> >>> 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 actually preferred the names from my original proposal:  toAbsolute and
> toRelative.  But someone (can't remember who) pointed out that
> toSomething functions by convention convert between types, and they're
> probably right.
> 
> > I think this is one case where it's just not worthwhile to force the
> > "function names should be verbs" guideline.
> 
> That seems to be the general consensus.  I'll keep the names as they are.

I'd argue that it's worth it for absolutePath and relativePath (I see no 
problem with makeAbsolute and makeRelative), and since Absolute and Relative 
aren't types and can't cause confusion in that regard, I don't really mind 
toAbsolute and toRelative either, but it does seem that not everyone agrees on 
that point.

- Jonathan M Davis