Why not add "protected" then for the fields that are only meant to be accessible by the implementation but not public ?
On Sun, Dec 15, 2013 at 1:51 AM, Peter Crosthwaite < peter.crosthwa...@xilinx.com> wrote: > On Sun, Dec 15, 2013 at 9:42 AM, Peter Maydell <peter.mayd...@linaro.org> > wrote: > > On 14 December 2013 23:06, Peter Crosthwaite > > <peter.crosthwa...@xilinx.com> wrote: > >> On Sat, Dec 14, 2013 at 6:26 AM, Antony Pavlov <antonynpav...@gmail.com> > wrote: > >>> What do the "< private >" and "< public >" comments exactly mean here? > >> > >> Private means inaccessible to everybody, including the implementation > >> of class being instantiated. No one should ever dereference a private > >> variable, they should be managed by QOM indirectly via casts if > >> needed. Public means that at least someone can access it. Note that > >> public does not declare a free-for-all. QOM class variables may be > >> "public" in the sense that the class implementation may access them. > >> Container devices however still can not, and they are private from > >> that point of view. > > > > I'm not sure I find this a terribly convincing explanation. Last time > > I asked this IIRC the answer was just "they need to be there for the > > output of the documentation generator". > > > > The usual definition of 'public' vs 'private' is "what can a user of the > > object rather than the implementor safely access?". That would be > > actually interesting to document IMHO. (I should resurrect my patch > > for marking those fields up with __private so we enforce it...) > > > > Yes, that means we really have three levels of access, but only tags > for two. Hence the confusion over public. > > Regards, > Peter > > > thanks > > -- PMM > > > >
