[swift-evolution] [Pitch] Improve the API Design Guidelines about protocol naming
jordan_rose at apple.com
Wed Apr 19 16:35:08 CDT 2017
That was probably about the ObjC importer, which does this (appends "Protocol") when there's a class and protocol with the same name in the same module. That doesn't necessarily mean it's the right thing to put in the API guidelines, though.
> On Apr 19, 2017, at 10:59, Gmail via swift-evolution <swift-evolution at swift.org> wrote:
> I seem to recall that something (maybe a WWDC session) mentioned something about protocols that in essence represent a single type would have the Protocol-suffix.
> Unfortunately I couldn’t find it (yet?). The closest I’ve found so far is http://asciiwwdc.com/2014/sessions/407 <http://asciiwwdc.com/2014/sessions/407> but I’m not sure that was it.
> > essentially when there's a conflict between a class name and a protocol name, we'll append protocol to the name of the protocol.
>> On 19 Apr 2017, at 17:55, Gwendal Roué via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> Le 19 avr. 2017 à 17:23, Gwendal Roué <gwendal.roue at gmail.com <mailto:gwendal.roue at gmail.com>> a écrit :
>>> Re: [swift-evolution] [Review] SE-0172: One-sided Ranges
>>> "RangeExpression" is an unexpected name. I was expecting "RangeProtocol", as in IteratorProtocol and LazySequenceProtocol. We need a consistent suffix for protocols that can't be named in -able, -ible, or named with a simple noun because the noun is already used by a concrete type. "-Protocol" should be that prefix: RangeProtocol.
>> A detailed look at API Design Guidelines  shows that this subject is not addressed:
>>> • Protocols that describe what something is should read as nouns (e.g. `Collection`).
>>> • Protocols that describe a capability should be named using the suffixes `able`, `ible`, or `ing` (e.g. `Equatable`, `ProgressReporting`).
>> Nothing is said for "protocols that describe what something but can't be named as nouns", or "protocols that describe a capability but can't be named using the suffixes able, ible, or ing".
>> For example: the name of the protocol for all ranges discussed with SE-0172 should be addressed by the first rule (because the protocol describes what something is rather than a capability). But that protocol can't be named Range because Range is already taken.
>> Such a situation comes rather easily:
>> - in an evolving code base, when a protocol is added on top of an existing type hierarchy which should be preserved (RangeProtocol added on top of Range, ClosedRange, etc.)
>> - at the birth of a code base, when a protocol coexists with a concrete type which rightfully deserves the noun claimed by the protocol.
>> IteratorProtocol and LazySequenceProtocol have set a precedent: maybe we should have the API Design Guidelines evolve with a third rule:
>> + When a protocol can't be named with a noun, or with an `able`, `ible`, or `ing` suffix, the protocol should be named using the suffix `Protocol` (e.g. `IteratorProtocol`).
>> What do you think?
>> Gwendal Roué
>>  https://swift.org/documentation/api-design-guidelines/ <https://swift.org/documentation/api-design-guidelines/>
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution