Hi Peter, It is true that an important argument for threating acronyms as word is based on the possibility of having multiple acronyms after each other. I don't think this argument becomes completely irrelevant just that right now we don't have such a type yet.
No, we had already agreed that a single uppercase acronym in a class > name was acceptable. I don't see such an agreement: Gary and I expresses a preference for acronyms as words, you and Andy a preference for having them uppercased, Stian said he would vote 0. > You had then gone on to refer to the case of > possibly having multiple acronyms, which we do not have. > I started the discussion with the goal "to do the casing so we can apply it consistently everywhere" and I mentioned the situation of multiple acronyms in my first mail. We are free to choose whatever convention we want, or decide not have a convention. I'm very much in favor of having a convention also so that extending frameworks (like clerezza) can adopt it, and I have a preference for the "threat acronyms as words" convention. Reto > > On 21 March 2015 at 05:15, Reto Gmür <r...@apache.org> wrote: > > Sure: RDFTerm, IRI, BlankNodeOrIRI and RDFTermFactory > > > > Reto > > > > On Thu, Mar 19, 2015 at 9:38 PM, Peter Ansell <ansell.pe...@gmail.com> > > wrote: > > > >> Hi Reto, > >> > >> Could you name the types that you are referring to? The image I am > >> looking at doesn't contain them: > >> > >> > >> > https://github.com/commons-rdf/commons-rdf/raw/master/api/src/main/resources/commons-rdf-class-diagram.png > >> > >> Thanks, > >> > >> Peter > >> > >> On 19 March 2015 at 22:47, Reto Gmür <r...@apache.org> wrote: > >> > Hi Peter > >> > > >> > In the clerezza version there are 3 and in the github version there > are 4 > >> > types in the API that would have to be renamed. Additionally there are > >> > classes in the implementations that follow the same pattern. > >> > > >> > I can live with either version, and would probably even want to stick > to > >> it > >> > even when new acronyms are in use. I would like to have a decision so > >> that > >> > we either adapt the github code when importing it or we change the > code > >> at > >> > clerezza commons rdf. > >> > > >> > Cheers, > >> > Reto > >> > > >> > > >> > > >> > On Wed, Mar 18, 2015 at 9:56 PM, Peter Ansell <ansell.pe...@gmail.com > > > >> > wrote: > >> > > >> >> Hi Retro, > >> >> > >> >> In our case, there is only ever one acronym in a class name at this > >> >> point, so we should be fine with just uppercasing it without dealing > >> >> with the complexities you are referring to. If we ever find ourselves > >> >> in a position with multiple acronyms in a class name we can come back > >> >> to it. > >> >> > >> >> Cheers, > >> >> > >> >> Peter > >> >> > >> >> On 18 March 2015 at 19:22, Reto Gmür <r...@wymiwyg.com> wrote: > >> >> > I think the approach Andy suggested isn't in the three options of > my > >> >> > original mail. So let me try to paraphrase it: > >> >> > > >> >> > d) If possible acronyms are cased as they appear in the specs > (default > >> >> > casing), if they appear in a position where an uppercase first > letter > >> is > >> >> > required (and this letter is not uppercase in the default casing) > then > >> >> only > >> >> > this letter is uppercased, if they appear in a position where a > >> lowercase > >> >> > first letter is required then the whole acronym is lowercased. > Where > >> >> > obvious readability improvements result a different casing can be > >> chosen. > >> >> > > >> >> > So for example (with RDF, RDFa, sbt and iOS): > >> >> > > >> >> > RDFSbtPlugin - rdfSbtPlugin > >> >> > RDFaSbtPlugin - rdfaSbtPlugin > >> >> > IOSRDFTools - iOSRDFTools > >> >> > > >> >> > Is this the variant you Peter/Andy prefer? > >> >> > > >> >> > Cheers, > >> >> > Reto > >> >> > > >> >> > > >> >> > > >> >> > On Tue, Mar 17, 2015 at 11:23 PM, Peter Ansell < > >> ansell.pe...@gmail.com> > >> >> > wrote: > >> >> > > >> >> >> +1, I prefer the current style and no clear reason why the other > >> >> >> possibility would be more beneficial for us at this point. > >> >> >> > >> >> >> Cheers, > >> >> >> > >> >> >> Peter > >> >> >> > >> >> >> On 17 March 2015 at 22:27, Andy Seaborne <a...@apache.org> wrote: > >> >> >> > I prefer the current style. It's more common and closer to the > >> specs. > >> >> >> > > >> >> >> > Java itself uses SOAP*, SQL*, XPath*, JMX*, JAXB*, HTML*, .. > and a > >> >> mix of > >> >> >> > Xml and XML, Http and HTTP. > >> >> >> > > >> >> >> > (With deviation from any rules where obvious readability > >> improvements > >> >> >> > result.) > >> >> >> > > >> >> >> > Digressing - I found that an identifier of "_" now generates a > >> >> warning in > >> >> >> > Java8 (not that I would use a single _ much refer $) becaue ti's > >> going > >> >> >> to be > >> >> >> > removed. Anyone know the background to that? Scala alignment > >> maybe? > >> >> >> > > >> >> >> > Andy > >> >> >> > > >> >> >> > On 17/03/15 09:51, Reto Gmür wrote: > >> >> >> >> > >> >> >> >> I know it's just a detail and there is no clear right or wrong. > >> Still > >> >> >> I'd > >> >> >> >> like to have a conscious decision on how to do the casing so we > >> can > >> >> >> apply > >> >> >> >> it consistently everywhere. > >> >> >> >> > >> >> >> >> Approaches: > >> >> >> >> A) Acronyms are treated like normal words, i.e. only the first > >> >> character > >> >> >> >> is > >> >> >> >> uppercased, this is what the google style guide recommends [1] > >> >> >> >> B) Acronyms are uppercased as a whole > >> >> >> >> C) 2-Letter acronyms are uppercased, longer are treated like > >> normal > >> >> >> words > >> >> >> >> (this seems to be the .Net convention) > >> >> >> >> > >> >> >> >> I personally prefer the first approach for the following > reasons: > >> >> >> >> - IDEs get it right, the default name for the result of > >> >> getRdfUiApiKey() > >> >> >> >> or > >> >> >> >> a field of type RdfUiApiKey is rdfUiApiKey (or uiApiKey, or > >> apiKey, > >> >> or > >> >> >> >> key) > >> >> >> >> not rDFUIAPIKey. > >> >> >> > > >> >> >> > > >> >> >> > Eclipse gets it right for any convention for me. > >> >> >> > > >> >> >> >> - It's more readable, the acronyms are the individual words, > the > >> case > >> >> >> >> distinctions allows to recognize them quickly > >> >> >> >> - It's not always obvious is something is an abbreviation or > any > >> >> >> acronym, > >> >> >> >> while it might seem OK to uppercase some abbreviations like > "OK" > >> or > >> >> "ID" > >> >> >> >> uppercasing other abreviations would look quite strange (e.g. > >> >> >> >> "LiteralIMPL"). So for consistency treat acronyms like > >> abbreviations > >> >> >> like > >> >> >> >> normal words. > >> >> >> >> > >> >> >> >> WDYT? > >> >> >> > > >> >> >> > ?Wdyt ! > >> >> >> > > >> >> >> >> > >> >> >> >> Reto > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> 1. > >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> > https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.3-camel-case > >> >> >> >> > >> >> >> > > >> >> >> > >> >> > >> >
