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

[Dave Abrahams]

on Sat Jan 23 2016, Thorsten Seitz <swift-evolution at swift.org> wrote:

> 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.
> This is the same as prefixing (or suffixing) variable names with
> something to express their type, e.g. `String sName` or `int iLength`.
> That’s what we have type information for. 
>
> 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? 

Yes, that was the original rationale, FWIW.

> Why not simply `Collection` if it describes what a collection is?  I
> guess its often more the problem of finding a suitable different name
> for the implementation 

Yeah, often we'd have a collision with an associated type.

> and that’s why I sometimes wonder whether it
> might make sense to give protocols their own namespace…

Can't do that as long as we have protocols that can function as concrete
types (existentials).

> 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).
>
> I’m open to debate, though :-)
>
> -Thorsten
>
>> Am 23.01.2016 um 06:25 schrieb Kevin Lundberg via swift-evolution
>> <swift-evolution at swift.org>:
>> 
>> > 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).
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> In short, appending Type (or something like it) i think is a
>> reasonable convention to keep around for non-behavioral protocols.
>> 
>> 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.)
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave