I wonder what conditions justify the use of protected / public fields? I can see how protected fields make more sense for a single user code because it is easier to not have all those getter/setter methods. But perhaps for an API with a wide audience, the commitment of providing a field is a big one. Is this the general view?
-Ajo On Thu, Jul 11, 2013 at 11:57 PM, Benedikt Ritter <brit...@apache.org>wrote: > A somewhat more academic rationale why making fields protected may be an > issue, can be found here: http://dl.acm.org/citation.cfm?id=28702 > > Benedikt > > > 2013/7/12 Ajo Fod <ajo....@gmail.com> > > > I see. That makes sense now. > > > > Thanks. > > > > On Thursday, July 11, 2013, Phil Steitz wrote: > > > > > On 7/11/13 12:09 PM, Luc Maisonobe wrote: > > > > Hi Ajo, > > > > > > > > Le 11/07/2013 20:38, Ajo Fod a écrit : > > > >> More classes can be used/extended if fields generally default to > > > protected > > > >> instead of private as it seems it does in classes in CM now. > > > >> > > > >> Case in point is in : > https://issues.apache.org/jira/browse/MATH-1003 > > > > In fact, having protected members is often not considered a good > thing. > > > > If for example you look at checkstyle VisibilityModifier check, you > > will > > > > see that its protectedAllowed property is set to false by default. > > > > > > > > For Apache Commons Math, we have decided to not use the default value > > > > and our setting in checkstyle.xml explicitly put protectedAllowed to > > > > true. However, this does not mean everything should be protected by > > > > default. It is rather a case by case decision, and we have a tendency > > to > > > > prefer restricting access than opening it.: as you have noticed there > > > > are more private than protected fields. > > > > > > > > In many cases, including the one you mention for inverting diagonal > > > > matrices, its seems safer to add a protected getter for the field > than > > > > putting the field itself protected. It allows read only access to > > > > derived class which seems sufficient in this case. In some other > cases, > > > > a setter may also be added, but direct reference to the field itself > is > > > > a dangerous thing that should be looked at precisely. > > > > > > +1 - we have mostly moved away from protected fields in commons > > > because once defined they become part of the public API. This > > > effectively locks us in to the specific data representation chosen > > > when they are defined, as well as obviously to the fields > > > themselves. Changing types or visibility breaks backward > > > compatibility. Protected fields are also directly mutable, making > > > thread-safety more difficult / expensive to ensure. > > > > > > Phil > > > > > > > > best regards, > > > > Luc > > > > > > > >> Cheers, > > > >> Ajo > > > >> > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > <javascript:;> > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > <javascript:;> > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > <javascript:;> > > > For additional commands, e-mail: dev-h...@commons.apache.org > > <javascript:;> > > > > > > > > > > > > -- > http://people.apache.org/~britter/ > http://www.systemoutprintln.de/ > http://twitter.com/BenediktRitter > http://github.com/britter >
