Re: [Question] What is the definition of “private” fields in QOM?

[Zhao Liu <zhao1.liu@intel.com>]

On Mon, Oct 21, 2024 at 03:20:39PM +0100, Peter Maydell wrote:
> Date: Mon, 21 Oct 2024 15:20:39 +0100
> From: Peter Maydell <peter.maydell@linaro.org>
> Subject: Re: [Question] What is the definition of “private” fields in
>  QOM?
> 
> On Mon, 21 Oct 2024 at 15:12, Zhao Liu <zhao1.liu@intel.com> wrote:
> >
> > Hi Peter,
> >
> > On Mon, Oct 21, 2024 at 10:25:07AM +0100, Peter Maydell wrote:
> > > Date: Mon, 21 Oct 2024 10:25:07 +0100
> > > From: Peter Maydell <peter.maydell@linaro.org>
> > > Subject: Re: [Question] What is the definition of “private” fields in
> > >  QOM?
> > >
> > > On Sat, 19 Oct 2024 at 16:54, Zhao Liu <zhao1.liu@intel.com> wrote:
> > > >
> > > > Hi maintainers and list,
> > > >
> > > > In the QOM structure, the class and object structs have two members:
> > > > parent_class and parent_obj, which are often marked as "< private >" in
> > > > the comment.
> > > >
> > > > I couldn’t find information on why to define ‘private’ and ‘public’,
> > > > even in the earliest QOM commits and the patch emails I could find.
> > >
> > > This is a rather old thing which I think was originally
> > > borrowed from glib's commenting convention.
> > >
> > > I'm fairly sure that we decided a while back that they were entirely
> > > unnecessary, so you don't need to add them in new code. (I can't
> > > actually find anything with a quick list search about that though
> > > so maybe I'm misremembering.)
> >
> > Thanks for your explanation! So I understand that directly accessing
> > parent_obj/parent_class is actually allowed.
> 
> No, you shouldn't do that. You can use a QOM cast of the
> object pointer to the relevant parent class if you need to
> treat it as an instance of the parent class.
>
> What I mean by "the private/public markers are unnecessary" is
> that they don't tell the reader anything, because all the fields
> in a QOM device struct are private.

This time I really understand the question of whether it's okay to
directly access parent_obj/parent_class. :-)

> If you're not in the implementation of that class, then you shouldn't
> really be directly touching any of the fields in the state struct.
> (In some places we take a shortcut and do it. But really it's almost
> never necessary.)

Thank you for your further explanation! I hadn’t noticed that. So, for
other code (code outside the class/object implementation) to access the
fields other than parent_obj/parent_class of class/state struct, the
most ideal way would be to use the set/get property interfaces as
much as possible instead of accessing them directly, right?

Regards,
Zhao