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.mayd...@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....@hotmail.com> wrote: > > Peter Maydell <peter.mayd...@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
