[swift-evolution] Proposal: conversion protocol naming conventions

Erica Sadun erica at ericasadun.com
Thu Mar 3 20:18:45 CST 2016


Adding onto what Dave said:

Although the notion of tying a protocol name to a specific method or function is superficially appealing, it
fails in my opinion for the following reasons:

* Protocols may not include any methods or function. A protocol may consist of one or more properties, subscripts, or associated types.
* Many protocols include multiple methods and functions. Which is the magic one that controls the naming?
* Protocols describe their purpose or their artifact. There may be no direct semantic connection from that purpose or artifact to a specific method or function name.
* The words Matthew and I propose are modifiers. The key semantics are found in the other half of the protocol name. "This item can be created from <some unifying concept>", "This item can be converted to and from <some unifying concept>" and "This item can be represented as <some unifying concept>".

Best regards,

-- E

> On Mar 3, 2016, at 6:42 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Thu Mar 03 2016, Howard Lovatt <swift-evolution at swift.org> wrote:
> 
>> I would prefer the name `Xxxable` to imply a method `xxx`. For example
>> `CustomStringConvertable` becomes `Describable`, because its method is
>> `description`. Similarly `IntergerLiteralConvertable` becomes
>> `IntegerLiteralInitializable` because it has an `init` with a
>> `integerLiteral` label. IE I am suggesting a one-to-one correspondence
>> between the main 'method' name and the protocol name with 'able'
>> added.
> 
> I don't know about this; I don't think I want to be forced to rename
> Comparable or Equatable.
> 
>> 
>> 
>> On Thursday, 3 March 2016, Bradley Hilton via swift-evolution <
>> swift-evolution at swift.org
>> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>> 
>>> Just going to put in my two cents: I think `Initializable` makes more
>>> sense than `Createable` or `Instantiable` assuming that we want to
>>> encourage protocols with initializers rather than static methods which
>>> aren’t as pretty. ;) I believe `Serializable` or `Representable` would be
>>> great for converting types to a given value. I’m also of the mind that
>>> `Convertible` should represent the combination of `Initializable` and
>>> `Serializable` protocols and may in many cases simply exist as a
>>> convenience protocol that inherits from the two.
>>> 
>>>> I have drafted a proposal to establish precise conventional meaning for
>>> the use of `Convertible`, `Representable`, and `Projectable` protocol
>>> suffixes. The proposal would require renaming `CustomStringConvertible` and
>>> `CustomDebugStringConvertible` to `CustomStringProjectable` and
>>> `CustomStringProjectable` respectively
>>>> 
>>>> I am seeking input on the proposal before submitting a PR. The full
>>> draft can found at
>>> https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md
>>> <
>>> https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md
>>>> .
>>>> 
>>>> Thanks,
>>>> Matthew
>>>> 
>>>> 
>>>> 
>>> _______________________________________________
>>> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list