[swift-evolution] SE-0005 ==> Please keep well know acronyms capitalized!

[David Hart]

Hi Pavel,

I don’t agree that capitalised acronyms read better for properties and variables. I’m happy that the naming guidelines went the way they did. But that is fairly inconcequential. As Brent puts it better than I ever could, the success of the evolution process is based on making peace with previously accepted proposal, even if you were not personally there when they were debated, and especially as this discussion is not putting forward new evidence or scenarios to further the debate. Many people with similar opinion to yours were there back then to plead your cause.

Anyway, welcome to the swift evolution mailing list!

David.

> On 19 May 2016, at 22:45, Pavel Kapinos via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Dear Brent,
> 
> I am sorry I touched your feelings here. I am here to state my opinion even if others already made their mind. I have just signed up to the list this morning. I will bring up my point again to be clear - well known acronym capitalization is pervasive in Cocoa APIs and as a result enable fast and easy comprehension and writing good quality code. IMO it is quite important for future preservation in Swift 3. Have a good day!
> 
> Cheers,
> Pavel.
> 
>> On May 19, 2016, at 1:38 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>> 
>>> Thank you for you encouragement! Please join in to support it **now**!
>> 
>> I wasn't trying to encourage you to fight. Quite the opposite, actually.
>> 
>> In order for swift-evolution to work—to make progress on the language and not suck up infinite time—one of the most important things we, as list members, must do is know when to stop arguing about something, even when we've lost. And the time to argue about this was during the drafting and review of SE-0005. There was ample debate on the list about this specific subject, with many positions represented.
>> 
>> I was on the side that argued for maximally accurate representation of words, including all-caps acronyms even at the beginning of lowercase strings. Others argued that the first word of a non-type should always be lowercase; still others argued that all letters should be lowercase except for the first one after a word boundary, even in an acronym. If we take the example of a "URL handler" property and an "HTML string" type, there were people arguing for `URLHandler` and `HTMLString`, for `urlHandler` and `HTMLString`, for `urlHandler` and `HtmlString`, even for `uRLHandler` and `HTMLString`. And we finally settled on the current convention, `urlHandler` and `HTMLString`, because it was least offensive to everybody: it kept the initial lowercase letter that some people wanted, while also not mixing the case of acronyms and giving a decent indicator of word boundaries.
>> 
>> This all took up a week or two of the list's time, and even though I didn't win the argument, I don't want to reopen it. It's been argued, it's been settled, and we need to move on to other designs. And you know what? `urlHandler` isn't *that* bad. It's not what I would have chosen, but it's something I can live with.
>> 
>> In general, I do not support reopening designs which have already been settled by a formal proposal, review, and core team acceptance, unless the decision is either egregiously bad (I can't think of any examples off the top of my head; perhaps the issues which led to the `form` prefix might qualify) or later experience has shown the design to be worse than previously thought. I will fight a design tooth and nail while it's being proposed and reviewed, but once it's accepted, I put aside my feelings, accept the proposal as part of the language's design, and move on with it. It's the only way we can get anything done here.
>> 
>> Rehashing old decisions like this is just spinning our wheels. There are lots of exciting new things we *haven't* decided—things like multiline string literals, Foundation and Dispatch designs, and a world of syntax clean-ups. Let's focus on those things—things where we can make forward progress, not keep revisiting old arguments.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution