<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 19, 2016, at 2:01 PM, charles--- via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Well known acronym capitalization is pervasive in Cocoa APIs and as a result it enables fast and easy comprehension and writing a good quality code.</span></font></blockquote></div><div class=""><br class=""></div><div class="">I could reply "they are confusing because they look like class names and clearly cause a higher number of errors in code.” </div></div></div></blockquote><div><br class=""></div><div>FWIW, this became an actual problem in practice with the introduction of SE-0069 (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md</a>), which bridges “NSURL” to a value type “URL”, so</div><div><br class=""></div><div> var URL: URL</div><div><br class=""></div><div>becomes an actual, practical problem that consistent lowerCamelCasing of values avoids.</div><div><br class=""></div><div><br class=""></div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">My *actual* view is that both forms cause problems, so it doesn't much matter which we go with. </div><div class=""><br class=""><div class="">Sent from my iPhone</div></div><div class=""><br class="">On May 19, 2016, at 1:30 PM, Pavel Kapinos <<a href="mailto:kapinos@twobytesoftware.com" class="">kapinos@twobytesoftware.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class="">Hi Charles,</span><br class=""><span class=""></span><br class=""><span class="">Thank you for your feedback! But we are not talking here bad or good names per se. Well known acronym capitalization is pervasive in Cocoa APIs and as a result it enables fast and easy comprehension and writing a good quality code. IMO it is quite important for future preservation in Swift 3. Have a good day!</span><br class=""><span class=""></span><br class=""><span class="">Cheers,</span><br class=""><span class="">Pavel.</span><br class=""><span class=""></span><br class=""><blockquote type="cite" class=""><span class="">On May 19, 2016, at 1:20 PM, <a href="mailto:charles@charlesism.com" class="">charles@charlesism.com</a> <<a href="mailto:charlesism.com@gmail.com" class="">charlesism.com@gmail.com</a>> wrote:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">I don't believe there's a correct answer here. Both urlHandler and URLHandler are bad names (for instances). Since we're stuck with camelCase, bad names are a fact of life.</span><br class=""></blockquote></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>