Re: [Qemu-devel] a QOM Coding Conventions question

[Pantelis Koukousoulas]

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 <address@hidden> wrote:

On Sun, Dec 15, 2013 at 9:42 AM, Peter Maydell <address@hidden> wrote:
> On 14 December 2013 23:06, Peter Crosthwaite
> <address@hidden> wrote:
>> On Sat, Dec 14, 2013 at 6:26 AM, Antony Pavlov <address@hidden> 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
>