<div dir="ltr">I think Kevin and I come from the same place and largely agree. I feel like this is trading in of accessibility and discoverability for the sake of terseness. This might be aesthetically pleasing but gives up many positive side effects the more descriptive names provide.<div><br></div><div>Consider the time before you knew you could or how to "check the documentation". Or the time spent scanning unfamiliar or long forgotten code.</div><div><br></div><div>These concerns might be eased if consideration was also being given to the first parameter rule. And the (now) odd difference between initializers and function parameter names. Apply the same rules as any parameter name.</div><div><br></div><div>Stealing Kevins example:</div><div><div style="font-size:13px"><br></div><div><div style="font-size:13px"><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;line-height:20px;white-space:pre-wrap;background-color:rgb(247,247,247)">let next = current.updating(proximity: p</span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;line-height:20px;white-space:pre-wrap;background-color:rgb(247,247,247)">)</span><br></div><div style="font-size:13px"><br></div></div></div><div class="gmail_extra">Not great but better.<br><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Feb 2, 2016 at 2:16 PM, Kevin Schlei via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sorry for the premature send! Continuing:<div><br><div><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;line-height:20px;white-space:pre-wrap;background-color:rgb(247,247,247)">let content = listItemView.text.trimming(.</span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;line-height:20px;white-space:pre-wrap;background-color:rgb(247,247,247)">whitespaceAndNewlines)</span><br></div><div><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;line-height:20px;white-space:pre-wrap;background-color:rgb(247,247,247)"><br></span></div><div>For a beginning programmer, there is no indication of what .trimming does. In this case, it returns a new string instance. Where is that explained? In the documentation. Nowhere near the method call.</div></div><div><br></div><div>So are we reduced now to looking up documentation just to read code? What does this line do:</div><div><br></div><div><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;line-height:20px;white-space:pre-wrap;background-color:rgb(247,247,247)">let next = current.updating(p</span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;line-height:20px;white-space:pre-wrap;background-color:rgb(247,247,247)">)</span><br></div><div><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;line-height:20px;white-space:pre-wrap;background-color:rgb(247,247,247)"><br></span></div><div>It's 100% unclear because you're relying on parameter names to contain all the hints. But this line:<span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;line-height:20px;white-space:pre-wrap;background-color:rgb(247,247,247)"><br></span></div><div><br></div><div><div><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;line-height:20px;white-space:pre-wrap;background-color:rgb(247,247,247)">let </span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;line-height:20px;white-space:pre-wrap;background-color:rgb(247,247,247)">next</span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;line-height:20px;white-space:pre-wrap;background-color:rgb(247,247,247)"> = current.locationByUpdatingProximity(p</span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;line-height:20px;white-space:pre-wrap;background-color:rgb(247,247,247)">)</span><br></div></div><div><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;line-height:20px;white-space:pre-wrap;background-color:rgb(247,247,247)"><br></span></div><div>Lets you know that:<br></div><div><br></div><div>1. we're returning a <b>'location'</b></div><div>2. '<b>by</b> <b>updating' </b>current with a new <b>'proximity'</b></div><div><br></div><div>When is the last time you saw a gerund (-ing) as a method name? I wouldn't let my students write that. Gerunds make good boolean properties. How would you even read the first line above out loud? Probably by filling in the words in the second line, magically.</div><div><br></div><div>My second major issue is that autocomplete grouping is totally lost when dropping the type returned at the beginning of the call. How many of us learned a *ton* when we just autocompleted <font face="monospace, monospace">.stringBy</font><font face="arial, helvetica, sans-serif">? Look at all the things you can do! But by removing the 'useless word' (really don't like that flag name) we have no grouping of constructor methods.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">I see a lot of discussion on how to deal with 'with' and 'by' and other words, but I want to strongly suggest that the current naming practices provide context and clarity. It makes code readable and accessible. Don't forget about when you didn't know how to code! These method names are teaching tools!</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Finally, I just want to ask: why? What is the great benefit? Shouldn't clarity be prioritized over brevity (where have I seen that...) </font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">I can't put it better than another forums poster:</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="color:rgb(0,0,0);font-family:Roboto,sans-serif;font-size:14px;line-height:20px;background-color:rgb(232,232,232)">Does the Swift team seriously believe that systematically parsing and extensively munging patterns in not-quite-natural-language is tractable to support all the corner cases for? And that, even if it were, that it could avoid confusion in less-than-perfect codebases? The idea that this will somehow benefit a language, particularly one in which clear and obvious bridging is so vital is </span><i style="color:rgb(0,0,0);font-family:Roboto,sans-serif;font-size:14px;line-height:20px;background-color:rgb(232,232,232)">insane</i><span style="color:rgb(0,0,0);font-family:Roboto,sans-serif;font-size:14px;line-height:20px;background-color:rgb(232,232,232)">. The best it can do is a reasonable job, with some amount of either unfixable brokenness forced upon developers in perpetuity, or constant churn stemming from perpetual fixing of brokenness. Swift's translation is currently simple to reason about, and the language as a whole has got a really great thing going on. I'm really happy with where it is at this moment. Why ruin it by boneheadedly detonating the utility of two years of progress in literature and the library of online information about Swift? Seriously, why?</span><font face="arial, helvetica, sans-serif"><br></font></blockquote><div><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;line-height:20px;white-space:pre-wrap;background-color:rgb(247,247,247)"><br></span></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 2, 2016 at 1:04 PM, Kevin Schlei <span dir="ltr"><<a href="mailto:kevinschlei@gmail.com" target="_blank">kevinschlei@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I am strongly against the proposed changes to the translation of Objective-C APIs. I think the changes promote terseness for terseness sake, lose vital context in method names, and are a huge loss pedagogically.<div><br></div><div>If you teach programming, you'll know why this line will be a nightmare:</div><div><br></div><div><pre style="overflow:auto;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;margin-top:0px;margin-bottom:16px;line-height:1.45;padding:16px;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-wrap:normal;color:rgb(51,51,51)"><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;padding:0px;margin:0px;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;border:0px;display:inline;line-height:inherit;word-wrap:normal">let content = listItemView.text.trimming(.whitespaceAndNewlines)</code></pre></div></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>