[swift-evolution] [Review] SE-0023 API Design Guidelines

[Erica Sadun]

> Dave, Breaker of Worlds, Hammer of Cocoa, Bringer of Swift:
> 
>> Me:
>> The guidance says: "Protocols that describe what something is should
>> read as nouns (e.g. ).  Protocols that describe a capability should be
>> named using the suffixes , ible , or ing (e.g. Equatable ,
>> ProgressReporting )."
> 
> You dropped aout "able" before the comma.

1. That would explain a lot.
2. Cut & paste. I swear.

> Nitpickage: 
>> 
>> "should be named using -ble or -ing suffixes (e.g. Equatable,
>> ProgressReporting)". (no "a/i" mismatch, easier to read,
>> http://thespellingblog.blogspot.com/2008/12/spelling-words-ending-in-able-and-ible.html <http://thespellingblog.blogspot.com/2008/12/spelling-words-ending-in-able-and-ible.html>)
> 
> I don't understand how that improves things.  Some words just *do* use
> an "ible" form (e.g. fallible)

3. Because you were saying just ible not able and ible.  (see points 1 and 2)
 (Some day Able and Ible will be a web comic series about mutant supernatural linguists, I'm sure of it.)

> Substance, mostly picking up from stuff you've said in response:
>> 
>> Protocols should express well-defined, testable semantics. Their names
>> should express those semantics in a clear and succinct matter.,
>> specifically by naming what a conforming type is (use nouns), does
>> (use -ing suffixes), or a capacity it provides (use -ble
>> suffixes). For example, a protocol can be a `Collection` or
>> `DataSource`. It can do `ProgressReporting` or
>> `DownloadProcessing`. It can provide the capability for being
>> `Equatable` or `IntegerInitializable`.
> 
> That seems like a nice addition.
> 
>> Additionalage:
>> 
>> Matthew J and I add: https://github.com/apple/swift-evolution/pull/60 <https://github.com/apple/swift-evolution/pull/60>
>> <https://github.com/apple/swift-evolution/pull/60 <https://github.com/apple/swift-evolution/pull/60>> to introduce
>> precise conventional
>> meanings for conversion suffixes. (Createable, Convertible, Representable), which I'd love for you to consider
>> under the SE-0023 API Design Guidelines review. I think it's applicable.
> 
> Yes, let's get that on the review schedule after this.

Thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160201/dc54507d/attachment.html>