commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ajo Fod <ajo....@gmail.com>
Subject Re: Extensibility of CM classes
Date Fri, 12 Jul 2013 14:39:44 GMT
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 <britter@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.fod@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-unsubscribe@commons.apache.org
> > <javascript:;>
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > <javascript:;>
> > > >
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> <javascript:;>
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > <javascript:;>
> > >
> > >
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message