Re: [Qemu-devel] [PATCH 2/5] musicpal: qdevify musicpal-misc

[Peter Maydell]

On 15 February 2013 15:14, Paolo Bonzini <address@hidden> wrote:
> I like the empty-except-for-parentclass.  OTOH, if you have no fields
> you will not use FOO_CLASS.  You will only use PARENT_CLASS, and those
> uses will be fine even after you start having a FooClass.

OK, that makes sense I think, except there is one case where you
do need a FooClass&c even if you have no class fields, which is
when you can yourself be subclassed. You want to provide the subclasses
with all the types etc they need so they don't change if you have
to add a class field yourself in future.

I wrote this up for the wiki page: http://wiki.qemu.org/QOMConventions
===begin===

If your class (a) will be subclassed or (b) has member fields it needs
to put in its class struct then you should write all of:
* a <code>FOO_CLASS</code> macro
* a <code>FOO_GET_CLASS</code> macro
* a FooClass structure definition containing at least the parent class field:
 typedef struct {
     /*< private >*/
     MyParentClass parent_class;
     /*< public >*/

     [any fields you need]
 } FooClass;
* and your <code>TypeInfo</code> for this class should set the
<code>.class_size</code> field to <code>sizeof(FooClass)</code>.

These ensure that nothing in future should need changing if new
fields are added to your class struct, and that any subclasses
have the correct typenames available so they won't need to change
either even if your implementation changes.

If your class meets neither of the above requirements (ie it is a
simple leaf class) then:
* don't provide <code>FOO_CLASS</code> or <code>FOO_GET_CLASS</code>
* don't provide a FooClass structure
* leave the <code>TypeInfo</code>'s <code>.class_size</code> field unset.

If a change means a class which didn't provide these macros/types
now needs to provide them, then your change should add all of them
(ie move the class from the latter category to the former).

===endit===

If that has some agreement I'll take the 'caution' label off it :-)
and update this patch to match, ie remove the class macros and
typedef.

-- PMM