[swift-evolution] Proposal: conversion protocol naming conventions
Brad Hilton
brad.hilton.nw at gmail.com
Thu Mar 3 16:23:16 CST 2016
+1. This makes a lot of sense.
On Thu, Mar 3, 2016 at 3:03 PM, Howard Lovatt <howard.lovatt at gmail.com>
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.
>
>
> On Thursday, 3 March 2016, Bradley Hilton via swift-evolution <
> 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
>>
>
>
> --
> -- Howard.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160303/f01c7eab/attachment.html>
More information about the swift-evolution
mailing list