[swift-evolution] Proposal: conversion protocol naming conventions

[Erica Sadun]

Terms currently on the table:
can be initialized from: Instantiable, Initializable, Establishable
can build via factory method: Creatable, Building, Producer/Producing, Establishable
can be converted to: Representable, Expressible, Presentable, Projectable
can be represented as and instantiated by: Convertible, Representable

I'm going to courteously disagree with Brent ("I actually think `Representable` better implies two-way than `Convertible` does"). Here's my reasoning. Convertible implies a commutative or two-way relation. For example, a convertible car can be converted to a sedan style or an open style. A convertible sofa can act as a bed or a sofa. Convertible suggests a R b as well as b R a. The word means to change into a different form and be used in a different way. 

To represent means to serve as or to take the place of by accruing characteristics or qualities. This suggests that a R b is not the same as b R a. My lawyer can represent my legal interests but I cannot represent my lawyer in court. 

To create means to produce something new and cause it to exist. This is semantically distant from initializing. The current (badly named) IntegerLiteralConvertible means "a conforming construct can use an integer literal to establish an instance of itself". There are, as Matthew points out two tasks that might arise through protocols: the creation of an instance through a factory method and the creation an instance by passing a separate type to an initializer.

The latter case is what we see throughout and commonly in the current Swift standard library: A.init(b) -> a. Of the words that have been brought up so far, to instantiate and to initialize are the only two that describe this task. I do not believe this is well described  as conversion.

I assume the factory style is A.staticMethod(...) -> a. In such case, I've collected your suggestions plus a few others above.

Of these, I most prefer initializable (DoubleLiteralInitializable), convertible (RawConvertible, StringLiteralConvertible), and representable (CustomStringRepresentable). I have no particular feelings about factory methods at this time.

Finally, I grabbed the following from a quick search of release notes, just to get a sense that protocol renaming does happen:
LogicValue became BooleanType
Printable and DebugPrintable became CustomStringConvertible, CustomDebugStringConvertible
ExtensibleCollectionType was folded into RangeReplaceableCollectionType

-- Erica


> On Dec 15, 2015, at 4:40 PM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
> I really like Creatable for the first as it is general enough to handle initializers an factory methods.  Great idea!  Alternatively, we could use that for a fourth category covering factory methods and stick with Initializable for the first case.
> 
>> On Dec 15, 2015, at 5:30 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>> 
>>>>> resentable is probably a lot better than CustomStringRepresentationExpressible
>>>> 
>>>> Representable is what I would have used if I wasn't trying to make a minimal change or if RawRepresentable didn't already use it for bidirectional conversion, so I agree that it is better than both Expressible and Projectable.
>>> 
>>> Let's run with the idea that everything is up for grabs and that better names will better serve the developer community in the long run. In such a case, if the core naming patterns were established as Convertible for bidirectional conversion, would RawConvertible be such a bad thing?
>> 
>> I actually think `Representable` better implies two-way than `Convertible` does. A representation is a way of expressing something in a different form; a conversion is a specific act of transforming one thing to another. To me, the former sounds more like a round trip than the latter.
>> 
>> So I suggest:
>> 
>> 	protocol IntegerLiteralInitializable {...} // or maybe ‘Creatable’, to cover the factory method case?
>> 	
>> 	protocol RawRepresentable {…}
>> 	
>> 	protocol CustomStringConvertible {…}
>> 
> 
> 
> 

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