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 > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
