[swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library
Dave Abrahams
dabrahams at apple.com
Sat Jan 30 22:11:27 CST 2016
on Fri Jan 29 2016, Erica Sadun <swift-evolution at swift.org> wrote:
> The "too specific" I'm railing against is that naming guidance should
> not depend on implementation details to
> the point it creates Hungarian Swiftisms.
I think we agree on everything after "that." I just don't see how the
guidelines as written would do that.
> -- E
>
>> On Jan 29, 2016, at 1:20 PM, Dave Abrahams <dabrahams at apple.com> wrote:
>>
>>
>> on Fri Jan 29 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
>>
>>>>> For example, for "HasNoun", I'd go with something more like
>>>>> NounContainingType or NounSupplier.
>>>>>
>>>>> Non-Abrahams Dave writes: "I like -Type for protocols that can only be
>>>>> used a generic constraint, and -able/-ible for protocols that can be
>>>>> “concrete” types.
>>>>>
>>>>> And Canonical Dave replies: "But that's not how they're used. I'd
>>>>> have to rename Equatable and Comparable to follow that convention."
>>>>>
>>>
>>> This is the big bit though and you didn't respond here, although it's
>>> mostly that I'm agreeing with you but what do you think about just
>>> cutting out things that get too specific? (I say the same more or less
>>> in the longer review email)
>>
>> I don't think that's going to fly. One of the main purposes of these
>> API guidelines is to remove the overhead of having to figure out how to
>> name things, at least as much as possible. Programmers and designers
>> have enough to think about. Teams that accept strong and specific
>> coding guidelines can spend more time effectively applying their domain
>> expertise and less time bike-shedding trivial details.
>>
>> --
>> -Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
--
-Dave
More information about the swift-evolution
mailing list