Re: [Qemu-devel] Re: [PATCH 01/10] Introduce qmisc module

[Luiz Capitulino <lcapitulino@redhat.com>]

On Sun, 18 Oct 2009 17:25:47 +0200
Paolo Bonzini <bonzini@gnu.org> wrote:

> 
> >> I'd strongly suggest making the JSON encoder live outside of QObject.
> >> There are many possible ways to represent a QObject.  Think of JSON as a
> >> view of the QObject model.  The human monitor mode representation is a
> >> different view.
> 
> My rationale was that since QObject is tailored over JSON, we might as 
> well declare JSON to be "the" preferred view of the QObject model.

 Maybe this makes sense today as the Monitor is the only heavy user
of QObjects, but I don't think we should count on that.

 As things evolve, I believe more subsystems will start using QObjects
and any "particular" view of it will make little sense.

 To be honest I don't know if this is good, I fear we will end up
enhancing QObjects to the extreme to do OOP in QEMU...

> The human monitor representation would be provided by qstring_format in 
> my patches (and a QError method would call qstring_format in the 
> appropriate way, returning a C string with the result).
> 
> I think the different opinions is also due to different background; mine 
> is in Smalltalk where class extensions---aka monkeypatching---are done 
> in a different style than for example in Python.  Adding a "write as 
> escaped JSON" method to QString would be akin to monkeypatching.

 True.

> >   I agree.
> >
> >   QObject's methods should only be used/needed by the object layer itself,
> > if the problem at hand handles high level data types (QInt, QDict, etc)
> > then we need a new type.
> >
> >   The right way to have what Paolo is suggesting, would be to have a
> > toString() method in the object layer and allow it to be overridden.
> 
> That's exactly what I did in my patches, except I called it encode_json 
> rather than toString.

 Okay, I just took a quick look at them and am looking at Anthony's
right now.

 Anyway, my brainstorm on this would be to have to_string() and have
default methods on all types to return a simple string representation.
The QJson type could override to_string() if needed, this way specific
json bits stays inside the json module.

 But I see that Anthony has added a qjson type already..