On Sun, Dec 15, 2013 at 7:02 PM, Pantelis Koukousoulas <pkt...@gmail.com> wrote: > Why not add "protected" then for the fields that are only > meant to be accessible by the implementation but not > public ? >
Ok by me if the documentation generation can be cleanly and easily taught to interpret this correctly. I don't know much about the docs TBH. Regards, Peter > > 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 >> > >> >
