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

[Joe Groff]

> On Jan 23, 2016, at 1:23 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Sat Jan 23 2016, Thorsten Seitz <swift-evolution at swift.org <mailto: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).

You've noted before that this is a recipe for confusion, especially if/when we ever extend existentials to cover protocols with Self and/or associated type constraints. It's probably a better long-term direction for the protocol type to be something you ask for (as "any<Protocol>", maybe), and for protocols to live in a separate namespace.

-Joe

> 
>> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160123/8ce5bb38/attachment.html>