[Qemu-devel] Re: [PATCH 01/25] Introduce QEMU dictionary data type

[Luiz Capitulino]

On Wed, 29 Jul 2009 16:57:10 +0300
Avi Kivity <address@hidden> wrote:

> On 07/29/2009 04:46 PM, Luiz Capitulino wrote:
> >>
> >> I'm worried about all those void *s as they move responsibility for type
> >> safety and lifecycle management to the user.  I'd much rather see a
> >> QObject (or Object) with the following methods:
> >>
> >>     clone() - deep copy an object; dicts will store copies so we'll avoid
> >> those leaks or a dictionary member modified after it was stored
> >>     destroy()
> >>     type() - return the type
> >>     as_dict(), as_string(), as_int() - convert to a subclass so its
> >> methods can be used
> >>
> >> Consider an operation such as printing out the dictionary, you have to
> >> know the types of the values.
> >>      
> >
> >   I was thinking in doing a little bit different.
> >
> >   My next patchset (phase 2) will introduce the QType (or QObject)
> > data type, as you have suggested in the QMP thread. This one will
> > have all those methods to convert from int, string, dict etc.
> >
> >   Then the dictionary can store it and the user can provide
> > a iterator to print the objects.
> >
> >   So, the point here is where to have the high-level data type
> > conversion: in the dict itself or in a higher layer (QObject).
> >
> >   I slightly prefer to have them in the QObject, this way the
> > dict is more flexible and simpler, capable of storing anything.
> >
> >   But I don't known where the clone() method should be, maybe in
> > both?
> >    
> 
> I meant QObject as a base type, so it is a lower layer than QDict; QDict 
> implements the QObject methods, as do QString, QNumber, etc.

 Ok, I'm failing at imagining "QDict implements the QObject methods"
in C, can you elaborate more and/or sketch something?

> The problem with void *, beyond requiring the user to know what the 
> object type is, is that it is impossible to control object lifecycle.  
> When you destroy a QDict containing void *, you cannot destroy the 
> contained objects.  On the other hand if QDict values are all QObjects, 
> then qdict_destroy() can call qobject_destroy() on all of them 
> (qobject_destroy might end up calling qdict_destroy() is a value 
> happened to be a QDict).

 Right, but as you said in other email, can we get this merged first
and then improve or should I do the change for this series?