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

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

On Tue, Oct 22, 2024 at 09:42:03AM +0100, Peter Maydell wrote:
> Date: Tue, 22 Oct 2024 09:42:03 +0100
> From: Peter Maydell <peter.maydell@linaro.org>
> Subject: Re: [Question] What is the definition of “private” fields in
>  QOM?
> 
> On Tue, 22 Oct 2024 at 04:24, Junjie Mao <junjie.mao@hotmail.com> wrote:
> > Peter Maydell <peter.maydell@linaro.org> writes:
> > > For Rust we get to make a fresh start on these things. If
> > > we do mark all these fields not public, what would break?
> > >
> >
> > The only thing that breaks today is std::mem::offset_of! which respects
> > field visibility. Defining a Property const structure requires getting
> > the field offset outside of the state context.
> >
> > To me properties are still private to the device state and must be
> > accessed via their getters & setters. A solution to that is to keep
> > properties private but make their offsets public in our alternative to
> > offset_of!.
> 
> Yes, conceptually I agree that the fields underlying a
> property are private and the public interface is the
> prop get/set API. (In C the prop/get set can if it
> likes do things like enforcing value limits, so looking
> directly at the underlying field would bypass that.)
> 
> At any rate it sounds like it would be a good idea to
> at least mark as not-public all the fields we can do that
> way, and have a comment
>   /* pub only because they are properties */
> for the fields used by the Property structs, even if we
> don't yet have a better way to deal with the latter.

Thank you both, Peter and Junjie!! I understand that the benefit of
declaring private states/classes in Rust is to avoid unnecessary
dependencies between different module/crates and to better manage
interactions between them. I'll go ahead and try out the methods you
both mentioned to compare them.

Regards,
Zhao