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 <[email protected]> > 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
