<div dir="ltr">(reply-all reposting, sorry I'm not very list-serve savvy)<div><br></div><div><span class="im" style="font-size:13px"><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"><div style="word-wrap:break-word">I think it's only unclear because p is not a descriptive name (next and current aren't terribly helpful either), and we don't have any context or type information.</div></blockquote><div><br></div></span><div style="font-size:13px">Put another way: it's up to variable names to clarify what a method does. I'm not in favor of that, and right now it's not broken. (To be clear: <span style="font-family:arial,helvetica,sans-serif">I'm all for properly naming variables. I hope everyone else is the same.)</span></div><div style="font-size:13px"><br></div><div style="font-size:13px">True, I intentionally chose ambiguous variable names to illustrate a point. However, I have to admit that when unpacking optionals I have caught myself doing this occasionally:</div><div style="font-size:13px"><br></div><div style="font-size:13px"><font face="monospace, monospace">if let p = proximity {</font></div><span class="im" style="font-size:13px"><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">}</font></div><div> </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"><div style="word-wrap:break-word">This is definitely more clear when you completely separate these lines from their context, but code isn't written or read in complete isolation like this, so I think these examples significantly exaggerate the ambiguity of the pattern in the real world.<br></div></blockquote><div><br></div></span><div style="font-size:13px">In my experience, encountering new code is an exercise in unpacking individual components in order to understand the whole. Making the individual parts convey less makes the whole thing harder to absorb.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 2, 2016 at 2:48 PM, <span dir="ltr"><<a href="mailto:swift@lng.la" target="_blank">swift@lng.la</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Feb 2, 2016, at 11:16, Kevin Schlei via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><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></div></blockquote><div><br></div></span><div>I think it's only unclear because p is not a descriptive name (next and current aren't terribly helpful either), and we don't have any context or type information.</div><br><blockquote type="cite"><div><div dir="ltr"><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></div></div></div></div></blockquote><div><br></div><div>This is definitely more clear when you completely separate these lines from their context, but code isn't written or read in complete isolation like this, so I think these examples significantly exaggerate the ambiguity of the pattern in the real world.</div><div><br></div><div>Even if you only make the minor change of renaming p to proximity (which is really what it should be), the first example becomes pretty clear:</div><div><br></div><div><blockquote type="cite"><div dir="ltr"><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(proximity</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></div></div></blockquote></div><div><br></div><div>Ultimately, I don't think this is a very difficult pattern to learn. Maybe the first handful of times you see it you'll need to read the documentation to know exactly what it's doing, but once you've seen it a few times, it's an instantly recognizable pattern. If you see a gerund method, it returns a new thing by doing the verb to the thing. Is it worth the redundancy and noise to save new developers from possibly needing to look at a method's documentation a few times?</div><div><br></div><div>I see the tradeoff here as a minor, essentially one-time decrease in clarity for new developers, and a small but indefinite increase in clarity for everyone else.</div><span class=""><div><br></div><blockquote type="cite"><div><div dir="ltr"><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></div></blockquote><div><br></div></span><div>Not having used this pattern before isn't a valid reason to not start using it, and the API design guidelines already provide a fine pattern for boolean properties, so we don't need gerunds for them.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><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></div></blockquote><div><br></div></span><div>I agree that this is kind of unfortunate, but I also don't think that it's a good idea to limit our API design for the sake of autocomplete discovery. Documentation is readily available and is a far better form of discovery since you don't just see things that start with the same prefix that you're using. The tradeoff is that you have to go out of your way to do it, but these are the kinds of good habits we should be teaching students.</div><br><blockquote type="cite"><div><span class=""><div dir="ltr"><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="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="font-family:Roboto,sans-serif;font-size:14px;line-height:20px;background-color:rgb(232,232,232)">insane</i><span style="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="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></span><span class="">
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></blockquote></div><br></div></blockquote></div><br></div>