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:;> > >
