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.mayd...@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....@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.mayd...@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....@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
