<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Many of Java's interfaces also conform to the standard swift uses, with things like runnable/comparable. Those define capabilities and are named with the same reasoning that the api guidelines propose, so it's easy to infer that they are interfaces from the name. I haven't worked in Java in a while so I could be forgetting other interfaces that don't follow this trend though, but interfaces in Java are more easily swapped with classes than protocols are in swift anyways (since protocols with associated types cannot be used as the type of a variable or whatnot).</div><div id="AppleMailSignature"><br>--<div>Kevin Lundberg</div></div><div><br>On Jan 23, 2016, at 10:27 AM, Haravikk &lt;<a href="mailto:me@haravikk.com">me@haravikk.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">Since I learned object-oriented programming in Java, I never understood the need for suffixes and prefixes at all, as Java’s package system makes for very simple namespaces for everything in the event that simply using a class/interface name is unclear.</div><div class=""><br class=""></div><div class="">I’d say that personally I don’t see why CollectionType shouldn’t just be Collection, in cases where several things are named Collection we should really have some kind of disambiguation mechanism anyway, perhaps with some special cases for specifying when you want a protocol rather than a class/struct.</div><div class=""><br class=""></div><div class="">In my ideal world every language would would follow Java’s example on name-spaces, while avoiding emulating its horrific security record ;)</div><br class=""><div><blockquote type="cite" class=""><div class="">On 23 Jan 2016, at 14:52, Thorsten Seitz via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I never liked the convention of distinguishing between interfaces and classes by prepending an „I“ for interfaces in other languages and I’m not overly fond fond of the suffix „Type“ currently used in Swift protocols.<div class="">This is the same as prefixing (or suffixing) variable names with something to express their type, e.g. `String sName` or `int iLength`.</div><div class="">That’s what we have type information for.&nbsp;</div><div class=""><br class=""></div><div class="">And because of the substitution principle it should make no difference whether I have a protocol or a struct or class. What is a `CollectionType` vs. a `Collection`? Is it the type of a `Collection`, i.e. a meta type? Why not simply `Collection` if it describes what a collection is?&nbsp;</div><div class="">I guess its often more the problem of finding a suitable different name for the implementation and that’s why I sometimes wonder whether it might make sense to give protocols their own namespace…</div><div class=""><br class=""></div><div class="">In short, I am not fond of the suffix „Type“ (but I would dislike the suffix „Protocol“ or prefixes like „I“ or „P“ even more).</div><div class=""><br class=""></div><div class="">I’m open to debate, though :-)</div><div class=""><br class=""></div><div class="">-Thorsten</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Am 23.01.2016 um 06:25 schrieb Kevin Lundberg via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt;:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
  
  <div bgcolor="#FFFFFF" text="#000000" class="">
    &gt; <strong class="">Protocols</strong> that describe what something <strong class="">is</strong>
    should read as
    nouns (e.g. <code class="highlighter-rouge">Collection</code>).
    Protocols that describe a <strong class="">capability</strong>
    should be named using the suffixes <code class="highlighter-rouge">able</code>,
    <code class="highlighter-rouge">ible</code>, or <code class="highlighter-rouge">ing</code>
    (e.g. <code class="highlighter-rouge">Equatable</code>, <code class="highlighter-rouge">ProgressReporting</code>).<br class="">
    <br class="">
    I personally like the idea behind the current convention for
    protocols that describe a thing (IntegerType, CollectionType, etc)
    where there is a suffix of Type appended to the end, so I give this
    specific part of the proposal a -1. The specific wording of the
    protocol's name is not so important as the recognition at a glance
    that this is a protocol vs a concrete type. I like being able to
    infer at a glance how I'm expected to use a specific type reference
    based on its name alone; otherwise I may have to refer back to the
    type definition to refresh my memory of whether or not it is in fact
    a protocol or is something else.<br class="">
    <br class="">
    This change could also lead to confusion among some developers. For
    someone who is new to Swift, would they know they should use Bool
    over Boolean if they've seen both types before? Both names look
    reasonable to store a boolean value, but the semantics of each type
    differ significantly. Someone may try to have a type conform to Bool
    instead of Boolean, which would obviously not work, but could cause
    some consternation for developers who don't know the difference by
    heart. Naming the protocol BooleanType at least calls out that this
    may not be conceptually the same as a plain boolean value, which
    could make a developer think twice before trying to use that over
    Bool.<br class="">
    <br class="">
    Removing some common prefix from these kinds of protocols could also
    run the risk of unintentionally shadowing type names, if someone
    wanted to write their own Collection or Error struct or class for
    instance, or if a pre-existing concrete type in their code turned
    out to unexpectedly shadow a protocol in a new dependency that they
    want to add. These situations would not cause any technical hiccups
    due to module namespacing, but it could lead to confusion when a
    developer forgets to qualify the name and tries to use one type
    where the other is expected.<br class="">
    <br class="">
    In short, appending Type (or something like it) i think is a
    reasonable convention to keep around for non-behavioral protocols.<br class="">
    <br class="">
    As far as alternatives to 'Type', I personally don't like the suffix
    'Protocol' as much (which is suggested as a disambiguation option in
    the related standard library review), since 'Type' is shorter, feels
    nicer to read, and describes the purpose of the protocol well to me.
    C#'s approach of prefixing all interfaces with a capital I would be
    even more succinct, but I personally don't think that approach would
    look nice to read either. (PCollection, PBoolean? Ick.) <br class="">
  </div>

_______________________________________________<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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div>_______________________________________________<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">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote></body></html>