I would support Option 3. Neither iPad nor NeXT are acronyms, so they needn’t fall under the same rule.
Rule A: Acronyms all lowercase, all uppercase URL -> urlString, URLRequest LaTeX -> latexSource, LATEXRenderer GIF -> gifRepresentation, GIFGenerator Rule B: Brand names all lowercase, first uppercase and rest as usual iPad -> ipadIcon, IPadDevices NeXT -> nextIcon, NeXTCompany LinkedIn -> linkedinIcon, LinkedInCompany Now you might argue that LaTeX is a brand name, so perhaps it should fall under rule B. Deciding whether something is an acronym or a brand name can evolve over time, and is something that should lay outside the naming guidelines I think. In the same way radar and scuba have become normal words, they are decided by culture. > On 6 May 2016, at 3:09 AM, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > > Terminology-wise, most of these are not acronyms > <https://en.wiktionary.org/wiki/acronym#Noun> (or initialisms > <https://en.wiktionary.org/wiki/initialism#Noun>), but you’re right that > that’s a third option consistent with the existing guidelines. > > Jordan > >> On May 5, 2016, at 08:56, Basem Emara <cont...@basememara.com >> <mailto:cont...@basememara.com>> wrote: >> >> Yes I digress and agree with you consistency is absolute key. Another >> thought came to mind: >> >> Option 3 3: Uppercase all acronyms including those with mixed casing. This >> is both consistent and clear. Isolating acronyms is important because they >> loose their meaning and bleed into word boundaries, so making even mixed >> acronyms all uppercase clearly identifies them. In context, that might be >> “supportsIPAD”, “LATEXRenderer”, “isNEXTPlatform”, and “signalingNAN”, >> alongside “IPADIcon”, “LATEXSource”, “NEXTLogo”, and “NANValue”.) >> >>> On May 5, 2016, at 11:41 AM, Jordan Rose <jordan_r...@apple.com >>> <mailto:jordan_r...@apple.com>> wrote: >>> >>> [resending to include list] >>> >>> Hm. I’m not sure why these words would be special, though—if we were going >>> to use underscores, shouldn’t we consistently go for “snake_case” or >>> something? >>> >>> (A leading underscore is also often used to denote something private in a >>> lot of conventions, including the standard library.) >>> >>> Jordan >>> >>> >>>> On May 5, 2016, at 08:38, Basem Emara <cont...@basememara.com >>>> <mailto:cont...@basememara.com>> wrote: >>>> >>>> Indeed the scenario has always been tricky for conventions. In both option >>>> 1 and 2, it looses the meaning, so I propose option 3 (which still sux too >>>> ha): >>>> >>>> Option 3: Surround with underscores to isolate the acronym with mixed >>>> casing. It clearly retains the original meaning since acronys already >>>> create ambigiouty. An added degree of ambiguity could lose it’s meaning >>>> complete. This way with underscores, it is clear what it is referring to. >>>> In context, that might be “supports_iPad”, “_LaTeX_Renderer”, >>>> “is_NeXT_Platform”, and “signaling_NaN”, alongside “_iPad_Icon”, >>>> “_LaTeX_Source”, “_NeXT_Logo”, and “_NaN_Value”.) >>>> >>>>> On May 5, 2016, at 11:26 AM, Jordan Rose via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>> Hi, everyone. Today in the API Design Guidelines >>>>> <https://swift.org/documentation/api-design-guidelines/> we have this >>>>> section on case: >>>>> >>>>>> Follow case conventions. Names of types and protocols are >>>>>> UpperCamelCase. Everything else is lowerCamelCase. >>>>>> >>>>>> Acronyms and initialisms that commonly appear as all upper case in >>>>>> American English should be uniformly up- or down-cased according to case >>>>>> conventions: >>>>>> >>>>>> var utf8Bytes: [UTF8.CodeUnit] >>>>>> var isRepresentableAsASCII = true >>>>>> var userSMTPServer: SecureSMTPServer >>>>>> >>>>>> Other acronyms should be treated as ordinary words: >>>>>> >>>>>> var radarDetector: RadarScanner >>>>>> var enjoysScubaDiving = true >>>>> >>>>> However, this doesn't directly address words that are conventionally >>>>> written with mixed case. Usually these are names, such as "iPad", >>>>> "LaTeX", or “NeXT”, but sometimes they’re just acronyms or initialisms >>>>> with very strong conventions, like “NaN”. (Yes, the FloatingPoint >>>>> proposal is what prompted this whole thing.) >>>>> >>>>> There are a few options for what we could do with these words to make >>>>> them consistent with our existing rules for words that are all-uppercase, >>>>> all-lowercase, or capitalized (first letter uppercase, remaining letters >>>>> lowercase). It’s pretty clear from the “utf8Bytes” example above that use >>>>> at the start of a “lowerCamelCase” identifier means uniformly downcasing >>>>> all of the letters: “ipad”, “latex”, “next”, “nan”. However, it’s unclear >>>>> exactly what operation is being applied to subsequent words in an >>>>> identifier: >>>>> >>>>> Option 1: Upcase the first letter, leave all the other letters alone. >>>>> This is consistent with all of the examples shown in the API design >>>>> guidelines, and produces “IPad”, “LaTeX”, “NeXT”, and “NaN”. (In context, >>>>> that might be “supportsIPad”, “LaTeXRenderer”, “isNeXTPlatform”, and >>>>> “signalingNaN”, alongside “ipadIcon”, “latexSource”, “nextLogo”, and >>>>> “nanValue”.) >>>>> >>>>> Option 2: If any letters are lowercase, upcase the first letter and >>>>> downcase all other letters. This is also consistent with all of the >>>>> examples shown in the API design guidelines, and produces “Ipad”, >>>>> “Latex”, “Next”, and “Nan”. (In context, that’s “supportsIpad”, >>>>> “LatexRenderer”, “isNextPlatform”, and “signalingNan”, alongside >>>>> “ipadIcon”, “latexSource”, “nextLogo”, and “nanValue”.) >>>>> >>>>> I prefer option 1 because I think it’s easier to recognize the original >>>>> form of the word; DaveA notes that under option 2 it’s easier to find the >>>>> word boundaries. >>>>> >>>>> (“NeXT” is an especially tricky case because without case it’s not >>>>> distinguishable from the normal word “next”. This situation is rare but >>>>> not nonexistent. Then again, “Apple” is not distinguishable from the >>>>> normal word “apple” either, and we seem to do fine there.) >>>>> >>>>> Thoughts? >>>>> Jordan >>>>> >>>>> P.S. The rules also don’t special-case all-lowercase initialisms, like >>>>> “mph” (for “miles per hour”). Under either option above, we’d get “Mph”. >>>>> If we want some other behavior, >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>> >>> >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
