On 08/23/2010 09:32 AM, Avi Kivity wrote:
Is bad? The answer would depend on whether OtherState implemented
methods or not. If OtherState has no methods, it's fine. If it has
methods, it's bad.
I don't see why. As long as you can manipulate all of MyDevice's
state via MyDeviceState methods, why do you care about OtherState at all?
See below.
Devices can contain references to structs and objects. If a Device
contains a reference to an object, the object should be stored in a
BusState which is a container of Devices. Therefore, the object
should inherit from Device.
I disagree. It's up to the author to decide whether to split a Device
into 1 or 15 objects.
If one of the other objects is also a subclass of DeviceState, then
you're probably violating that DeviceState's contract. But that's a
different (and trivial) matter.
(side point: in C no objects have constructors and methods. in C++
all objects have constructors and methods, even PODs)
Things that inherit from DeviceState have ctors/dtors. Things that
don't end up inventing their own and probably will do so poorly.
When implementing a C object model, you really need to have a base
object that everything inherits from. In glib, it's GObject.
Regards,
Anthony Liguori
