<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This is very cute but limited in terms of application. Recall that there are several members that can be described in protocols, not just method members, such as initializers, subscripts, etc. This is a nice rule to have in a personal style guide, but I think it's far too narrow for Apple-sourced guidance.</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jan 28, 2016, at 9:33 PM, Howard Lovatt <<a href="mailto:howard.lovatt@gmail.com" class="">howard.lovatt@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">For protocols named XXXble I think they should have a main method named XXX. If this were adopted then many protocol names would change, e.g.:<div class=""><br class=""></div><div class=""> 1. ForwardIndexType would be Advanceable because it has advance methods and method successor() would be renamed advance().</div><div class=""> 2. Indexable would be Subscriptable because it has a subscript method.</div><div class=""> 3. Etc.</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On 29 January 2016 at 05:03, Erica Sadun via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 27, 2016, at 11:42 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div class=""><br class="">on Wed Jan 27 2016, Dave <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Huh… Yeah, you’re right. I guess I saw “CollectionType” and<br class="">“CustomStringConvertible” or something and made a connection that<br class="">wasn’t there.<br class="">Well, FWIW, that convention (plus the occasional “HasNoun”, and<br class="">-ableType for constraining the element of custom collections) tends to<br class="">work well for me.<br class=""><br class="">What’s been the deciding factor between -Type and -able so far?<br class=""></blockquote><br class="">When there's no reasonable -able or -ible name, use -Type.<br class=""></div></div></blockquote></div><br class=""><div class="">This is where I never know whether to keep my nose out of things or just jump in. I find there are generally two kinds of protocols: verby-ones ("this is how this thing works") and nouny-ones ("this is what this thing is"). Here's the guidance I've been giving:</div><div class=""><br class=""></div><div class=""><i class="">Swift protocols describe the surface that connect a feature provider API with its consumer. Protocols establish a communication contract. They ensure a fit between each required member and the provider’s implementation. It’s like whether a virus can attach to a host cell’s receptors, or whatever the actual biological equivalent is. </i><i class="">The standard library describes protocols using nouns (typically ending in Type, e.g. MirrorPathType, MutableCollectionType, ErrorType) and adjectives (typically ending in ble, like Streamable, Strideable, ArrayLiteralConvertible). The former more commonly discuss what a conforming type is and the latter what it does. </i></div><div class=""><div class=""><i class=""><br class=""></i></div><div class=""><i class="">When naming a protocol, you’re not limited to Type and ble endings. Your protocol can be, for example, a DataProvider or a FloatConsumer. A protocol can describe a relationship DownloadProcessingDelegate or ListViewDataSource. You may implement an OutputDestination or an IntegerSink. The current API Design guidelines say "omit needless words", so you might prefer to go with DataProvider over DataProviderType or MirrorPath over MirrorPathType, but I wouldn't give much more constraint to naming beyond that.</i></div></div><div class=""><br class=""></div><div class="">For example, for "HasNoun", I'd go with something more like NounContainingType or NounSupplier.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">And Canonical Dave replies: "But that's not how they're used. I'd have to rename Equatable and Comparable to follow that convention."</div><div class=""><br class=""></div><div class="">I agree in that I'm not convinced it's the role of a protocol to describe implementation details. (I'd say the same for method names, but that's different thread about mutability and side effects, etc). Going that way leads you to over-designated hungarian-esque guidelines that I'd rather keep loose, friendly, and sensible.</div><div class=""><br class=""></div><div class="">-- Erica</div><div class=""><br class=""></div><div class=""><br class=""></div></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature"> -- Howard.<br class=""></div>
</div>
</div></blockquote></div><br class=""></body></html>