Honestly, I don't care that much about this naming. No offense! :) The APIs where we should put all our love are the abstracions (yes, once again! :)). All the rest are provider specific APIs that users will have to learn *one by one*, because each will have their own semantincs. In this scenario, I don't see the "getFoo()" vs "foo()" naming a real issue. I'll agree to use whatever naming convention is preferred, but I think we have more important stuff to focus on right now.
I'd change the "we need consistency for our users" quote by a "we need proper abstractions for our users". That's the important thing. On 22 January 2015 at 17:53, Zack Shoylev <zack.shoy...@rackspace.com> wrote: > I think getSomeField() is more explicit and more in line with existing APIs > (consistency-wise). > Since AutoValue is/should be transparent to users, I don't think that the > default is that important :) > However, someFiled() is more concise and more in line with immutable object > semantics. > > What APIs (that have not been converted to AutoValue yet) use getSomeField()? > (the openstack ones do, but are there many others?). Since part of the > question is about consistency, perhaps we should compile a list first of what > uses what style. > Thanks! > ________________________________________ > From: Ignasi Barrera [n...@apache.org] > Sent: Thursday, January 22, 2015 4:15 AM > To: dev@jclouds.apache.org > Subject: Re: AutoValue Naming Conventions > > My preference would be to use the "someField()" form, which is the > default AutoValue used one. In my opinion, this naming convention also > enforces the concept of immutability with the absence of get/set > semantics. > > On 16 January 2015 at 19:15, Jeremy Daggett > <jeremy.dagg...@rackspace.com> wrote: >> Hi devs, >> >> Can we determine the AutoValue naming conventions to use across the codebase >> going forward? Do we continue with accessors like “getSomeField()”, versus >> “someField()” as was introduced in the labs repos? For example, take a look >> at the jclouds-labs-google repo Address[2] and Bucket[3] classes. >> >> Opinions? We need consistency for our users, so any feedback is appreciated. >> Thanks! >> >> /jd >> >> [1] https://github.com/jclouds/jclouds/pull/646 >> [2] >> https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Address.java#L35 >> [3] >> https://github.com/jclouds/jclouds-labs-google/blob/master/google-cloud-storage/src/main/java/org/jclouds/googlecloudstorage/domain/Bucket.java#L41 >>
