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