[swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift

Mon Feb 1 17:21:14 CST 2016

>> All of punctuation, symbols, parentheses, operators, abbreviations, etc. have the same problem -- they don't cleanly verbalize, and you have to some work to do that.
>> 
>> Should we get rid of all of that too? Should we try to make all of Swift "read naturally" as English-like sentences?
>> 
>> To me, that sounds absurd. You don't try to read code as if it was prose. It just makes no sense.
>> 
> 
> I don’t think we need to create a straw man idea of removing all punctation from Swift.

You’re right, my apologies.

What I tried to convey is: if there is (AFAICT) an agreement that trying to make code in general sound like English isn’t a very useful goal, perhaps the attempt to put ‘with’s etc in method names is more due to familiarity with how it was always done in Objective-C, rather than because it’s truly helpful in practice.

> 
>> And I don't see why we should have a double standard for method names. They're still words and easy to say out loud. You don't need to litter code with vacuous words like "with" to do that.
>> 
> 
> This concept is naturally difficult to discuss over email since the point I am trying to make is about how you read these methods in person, but I’ll try.
> 
> Let’s take a method like:
> 
> -encodeWithCoder:
> 
> then, translated into Swift by dropping the ‘with’:
> 
> encode(coder:)
> 
> If you say this out loud, you hear: “encode coder”. This sounds like you’re encoding the coder, which is not the case.

That is a good example. When you read the code, there is no ambiguity as the Swift punctuation makes it clear you’re “encoding” not “encoding coder”, but indeed trying to say it out loud can be confusing.

I believe this is something of an edge case, though. In vast majority of cases (as far as I can see), removing “with”s makes verbalizing a method name a little less “nice”, but I don’t consider it a real problem, and would strongly side for readability / high S-to-N in the natural medium. But when the result is downright confusing — okay, I could see why this could be considered a problem.

> I think in this particular method, a fair argument could be made that ‘with’ was not the right word to use in the first place, and instead it could have been “into”. Then it would probably be imported as “encodeInto(coder:)”. This sounds much more fluent while at the same time providing a more correct indication of the behavior. This is a direction that we are still exploring based on some of the feedback from the community in these review threads about the guidelines.

FWIW I’m not sure if “encode into coder”, verbalized, is an improvement in this respect. But I see what you’re going for.

> 
> It’s probable that this aspect of naming is more important to some people than to others. Personally, every day I talk to people using these method names. Often I get up on stages and talk about these methods to large groups of people. I believe that anything that helps me to say them out loud more naturally will assist in the listener’s ability to clearly understand my intent.

Definitely a great perspective to consider. I just wouldn’t want the clarity in code’s natural medium to suffer because it’s a bit harder to present and say out loud.

Best,
— Radek

> 
> Thanks,
> - Tony
> 
> 
>> Sent from my iPad
>> 
>> On 01 Feb 2016, at 09:19, Colin Cornaby <colin.cornaby at mac.com <mailto:colin.cornaby at mac.com>> wrote:
>> 
>>> I think being able to naturally talk about code is important. Code is not write only. It’s meant to be read, talked about out loud, and reasoned about with others. Certainly “with” (and “using”) can be trimmed out of a lot of API, but I’m not supportive of taken that to an extent where functions need to have words inserted back into them to be naturally read out loud. It only generates confusion if the method name as spoken is different than the method name as written.
>>> 
>>>> On Jan 30, 2016, at 7:45 AM, Radosław Pietruszewski via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>>> It’s important to be able to talk about these methods in a natural way, and a natural way to say this sentence in English is to put that connecting word there.
>>>> 
>>>> 
>>>> Why is this so important? You’re saying “this sentence”, but it’s not a sentence, and it’s not English. You can easily add the words “with” or “and” when trying to verbalize method names, but those words don't help at all in readability of code in its natural medium.
>>>> 
>>>>> One option we discussed was to put the connecting word into the label instead of the method name:
>>>>> 
>>>>> foo(withOptions:)
>>>>> description(withLocale:)
>>>> 
>>>> Having “options” and “locale” on the parameters side of the method call is great, but then if you make this effort, there’s no value in keeping “with”.
>>>> 
>>>> — Radek
>>>> 
>>>>> On 29 Jan 2016, at 22:18, Tony Parker via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>>> 
>>>>>> On Jan 29, 2016, at 12:07 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Jan 28, 2016, at 14:15, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>>> 
>>>>>>>> I'm very used to "fooWithBar: baz" meaning either "get me the foo that
>>>>>>>> has a bar matching baz" or "create me a foo with its bar set to
>>>>>>>> baz". 
>>>>>>> 
>>>>>>> That's great, when that's what "with" means.
>>>>>>> 
>>>>>>>> But I'm not sure this new convention is any worse, now that the base
>>>>>>>> name isn't assumed to include the first argument.
>>>>>>> 
>>>>>>> The problem is that, I'm guessing at least 50% of the time, "with" is
>>>>>>> just used as a vacuous connector to make the method name sound
>>>>>>> grammatical, and "fooWithBar" doesn't actually mean the "foo" has-a
>>>>>>> "bar."  In these cases, it's actively misleading. I know that's not what
>>>>>>> you were posting about, but I felt it had to be said :-/
>>>>>> 
>>>>>> I actually don't think this is true when "foo" is a noun (and searching through the selector dump Doug made a long time ago seems to back that up).
>>>>>> 
>>>>>> Exceptions:
>>>>>> - "fooWithOptions", but that's already caught by the default parameter rule.
>>>>>> - "fooWithLocale", which uses the locale to build the result.
>>>>>> - "commonPrefixWithString", where the "with" isn't quite vacuous.
>>>>>> 
>>>>>> But when "foo" is a verb (or when it's a later parameter that's just "withBar") it does seem pretty vacuous.
>>>>>> 
>>>>>> Jordan
>>>>>> 
>>>>> 
>>>>> It’s important to be able to talk about these methods in a natural way, and a natural way to say this sentence in English is to put that connecting word there.
>>>>> 
>>>>> One option we discussed was to put the connecting word into the label instead of the method name:
>>>>> 
>>>>> foo(withOptions:)
>>>>> description(withLocale:)
>>>>> 
>>>>> etc.
>>>>> 
>>>>> - Tony
>>>>> 
>>>>> _______________________________________________
>>>>> 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/20160202/925e1b22/attachment.html>