[swift-evolution] Proposal: conversion protocol naming conventions

[David Waite]

For "build via factory method", why not Factory or Manufacturer?

For "can be converted to", I can understand wanting to stay away from Convertible - but we should avoid it for round-trip conversions as well. To convert is the action of changing from one form to another (water into wine), without regards to changing back. Convertible is a property, and thus often means you are able to change from one form to another repeatedly. But there are edge cases for both conditions.

Converters to string form are difficult as there is a certain amount of presentation. An NSDate needs to understand a locale, a floating point number or currency may have desired display rules beyond a locale. This is I suspect why there is a CustomDebugStringConvertible variant that possibly exposes more/different info.

-DW


> On Dec 15, 2015, at 5:30 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 <mailto: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 <mailto: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 {…}
>>> 
>> 
>> 
>> 
> 
>  _______________________________________________
> 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/20151215/d149f5e8/attachment.html>