std.path review: second update

Lars T. Kyllingstad public at kyllingen.NOSPAMnet
Wed Aug 3 01:35:10 PDT 2011


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.


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

-Lars


More information about the Digitalmars-d mailing list