[swift-evolution] Requesting a team ruling on the next step, please Re: Proposal: conversion protocol naming conventions

Wed Dec 16 10:47:03 CST 2015

Thanks Dave, I appreciate the feedback and am happy to hear that you would like to solve the problem it addresses.

The proposal itself is somewhat out of date at this point so please be sure to catch up on the discussion in this thread when catching up.

And take your time.  There is certainly no rush on this, we just wanted to know how we should proceed.  Waiting for the API guideline team to discuss is a very reasonable answer!

Matthew

> On Dec 16, 2015, at 10:36 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi Erica, Matthew, et. al.
> 
> I've been watching this discussion with interest; thank you for initiating it—but I've just returned from vacation to over 6K (!) new emails and haven't had time to dive into this yet.  
> 
> As noted below, it's an API change so, a formal proposals will be needed, though I'm not sure I understand the distinctions between 2, 3, and 4 below.   I think the eventual proposal should for changes that enshrine these patterns in the API guidelines, and as a consequence applies the new guidelines to the standard library.
> 
> However, I think the standard library team probably ought to weigh in on the specifics before we move on to next steps.  At a high level, I like the direction of this proposal; it addresses a real naming issue that had escaped my notice.  I'll try to respond with specifics this afternoon, after I've had a chance to read through it in detail and after a meeting of the team that has been developing the API guidelines.
> 
> Thanks again for your efforts and your patience,
> Dave
> 
>> On Dec 16, 2015, at 7:55 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Thank you
>> 
>>> On Dec 16, 2015, at 8:20 AM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>>> 
>>> It would be helpful if someone from the core team can comment on whether you would prefer:
>>> 
>>> 1. A bug report (unlikely as it changes public API)
>>> 2. The current proposal with minimal changes to current state
>>> 3. A proposal with larger changes containing the names preferred by the authors without regard for current state
>>> 4. A proposal with several options to be considered and selected from during review.
>>> 
>>> I will update my PR accordingly.
>>> 
>>> Thanks,
>>> Matthew
>>> 
>>>> On Dec 15, 2015, at 9:46 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> I suggest you run this by team members to see if they want this as a bug report or a formal proposal. Either way, I suggest you offer the Swift.team a bunch of names in the order you prefer for the three cases (glomming together factory/init) without having to settle on any of them specifically.
>>>> 
>>>> This is kind of a no-brainer implementation-wise and I think offering better names for common protocol patterns is a big win for long-term language coherence. Swift.central has a history of improving names and I suspect there's at least one or two members who drove those efforts.
>>>> 
>>>> -- E, who thinks you're in good shape to move forward either way
>>>> 
>>>> 
>>>>> On Dec 15, 2015, at 8:34 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>>>>> 
>>>>>> 
>>>>>> For "build via factory method", why not Factory or Manufacturer?
>>>>> 
>>>>> I don’t think that accurately portrays this case.  The Factory and Factory Method patterns are quite different.  We are talking about factory methods that create instances of the conforming type itself with a parameter of the type described by the protocol.  We are not discussing a type that is a factory producing instances of other types.  
>>>>> 
>>>>> I am not convinced that distinct conventions for the initializer case and the factory method case are worthwhile.  They are two mechanisms for taking an instance of one type and getting back an instance of another type.  In a significant sense the use of an initializer or a factory method is an "implementation detail" of the protocol.	
>>>>> 
>>>>> It is probably better to form protocol naming conventions around the high level purpose of the protocol and not how that purpose is fulfilled by the protocol.
>>>>> 
>>>>>> 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.
>>>>> 
>>>>> I am definitely not in love with Convertible.  It does seem to have a lot of potential for confusion exhibited by its use for different senses in the standard library.  Do you have any suggestions of this?
>>>>> 
>>>>>> 
>>>>>> 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 <mailto: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>
>>>>>>  _______________________________________________
>>>>>> 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>
>>>> _______________________________________________
>>>> 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>
>> _______________________________________________
>> 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>
> 
> 
>  _______________________________________________
> 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/20151216/a04f6cd8/attachment-0001.html>