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

[Thorsten Seitz]

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? 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 and that’s why I sometimes wonder whether it might make sense to give protocols their own namespace…

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

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