[swift-evolution] Proposal: conversion protocol naming conventions

[Matthew Johnson]

Thank you for taking the time to put together this summary and analysis Erica!  

In thinking about this further I am not convinced that separating the initializer and factory method variants into separate conventions is a good idea.  If we do that it would raise a question as to whether we should also have variations of the bidirectional protocol for both initializers and factory methods and I think that is going to far.  So I am currently leaning towards sticking with three conventions.

If we do that I definitely lean towards Creatable.  While initializers do not create an instance directly an instance is created every time they are used (leaving failable and throwing initializers aside for sake of discussion).  Calling an initializer does “produce something new and cause it to exist”.  It seems appropriate to me.  An alternative might be Constructible, however that doesn’t seem appropriate in Swift as it implicitly references “constructor” in a programming context.

BTW, the factory method case seems especially important to consider in the context of the problems with retroactively conforming classes in Foundation and other Apple frameworks to protocols which include object instantiation.  It isn’t clear yet how that problem will be solved and it is possible that we may see a solution that works for factory methods sooner than (or in lieu of) a solution that works for initializers.  The factory method case is potentially more tractable because the return type is specified in the function declaration rather than being implicit.

Matthew


> On Dec 15, 2015, at 6: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
> 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/01d4ad32/attachment.html>